Moving my SVN to Assembla, from local, given UUID error

Question

I read this post, and am ready to use --force-uuid.

However, my programmer suggested that I could also do a fresh checkout on my server, just in case Assembla and the existing TortoiseSVN format aren't identical (moving to Assembla, let's be fresh/clean).

I'm not totally comfortalbe doing that, because I didn't initially set up the SVN myself and am not fluent in server/SVN management.

Is there any possible damage or risk to forcing the UUID to match?

Any direction is greatly appreciated.

Answer 1

Let's separate out the client from the server...

I am assuming that Assembla is where your repository is stored. This is your Subversion server.

TortoiseSVN is the software you're using to checkout the software from your server. This is your client.

First, let's talk about the server.

Each Subversion repository that is on your server has what is called a Universally Unique Identifier (UUID). This is created when you create the Subversion repository. How does Subversion generate the UUID and know that there is absolutely no other in the Subversion repository in the entire world that doesn't share this UUID? It really doesn't, but it's not very likely that there's another Subversion repository with the UUID. The UUID is generated based upon the time, the IP address, and the MAC address, plus some pseudo-random values.

Since the UUID is guaranteed to be unique for any Subversion repository in the entire world, your Subversion client can use it to make sure it's talking to the same repository that you did your original checkout from.

When you move your Subversion repository from one location to another, you have to create a new Subversion repository where you can load in your data. Since this is really the same repository as before, the Subversion load command allows you to reset the new Subversion repository's UUID to be the same as the old.

Notice this is done:

1. On the server
2. At the time you import your data into the repository

This is not done by your client software since this is the server side of the issue.

---

Now, we're going to talk about your Subversion client which in this case is TortoiseSVN

When a Subversion client does a checkout into a working directory, it keeps track of the URL from where you did the checkout, and the UUID of that repository.

Let's take a look at your working directory using TortoiseSVN. Right click on your Subversion checkout folder, and select Properties on the bottom of the drop-down context menu. Don't go into the TortoiseSVN sub-menu! Select the Properties menu item from the bottom of the context menu.

Click on the Subversion tab. You'll see several pieces of information. Two of them are the URL where the checkout occurred, and the UUID of the repository.

When you right-click on the checkout folder and do a TortoiseSVN->Relocate, you can change the URL where the checkout occurred. However, you cannot ever change the UUID for that checkout.

That's because your Subversion client is using this to make sure that even if you've moved your Subversion repository to a new server, you're talking to the same repository.

---

What can you do if you've moved your repository, but didn't make sure the UUID is the same? Here are several solutions from best to worst.

• Do a new, fresh checkout. This is the BEST option. Before you moved your Subversion repository, you should have checked in all of your changes. If not, you can use the Status to find your changes and copy them to your new, fresh checkout.
• Reload the repository with the old dump file and this time make sure you use the --force-uuid flag.
• It is possible to change the UUID on the Subversion server by manually editing the UUID. The Subversion server's UUID is stored in the db/uuid file on the server. You can find the old UUID in an old checkout (see above). Simply change the UUID in the db/uuid file inside the Subversion repository directory. Remember one false move and you completely destroy your ability to ever read your repository again. Your company will lose the entire source code, go bankrupt, and everyone at your work will lose their job and hate you forever. No pressure.
• Hack your Subversion checkout to change the UUID to the new UUID. The UUID is in the .svn\entries file in each and everyone of your directories you've checked out. If you're using Subversion 1.7 based clients, all bets are off. I believe the UUID might be encrypted. This might work, but then it might create a corrupted checkout that will end up damaging the master repository if you attempt to commit your changes.