Last week the hard drive on my Subversion server failed and I had to rely on my backups to bring up a new server. My most recent backup was not 100% current, so I ended up with a Subversion repository at revision 935, but a working copy at revision 953. This is the story of how to reconcile the working copy with the backup so that your latest work is once again in your repository, on a Mac.
First, I looked for a way to simply import my working copy, along with any version info that it might have, but that doesn’t seem to exist. Then, I tried just committing a new revision to the repository, (it had the same URL as the one on the failed hard drive), but that lead to subversion errors. It turns out, that if your working copy has a revision number that is higher than that in the repository, you need to check out a new working copy, then copy changes from your old working copy into your new one, the commit your changes to the new working copy. It sounds easy enough, but there are a couple of gotchas to watch out for, like those pesky .svn folders, so here is a recipe for merging a working copy with an outdated repository, so that the repository is brought up to date:
- In your existing working copy, (I’ll call this the “old working copy” from now on), make sure that you’ve done an
svn addfor any files that are not yet under version control but you want to make the transfer. - Check out a new working copy from the outdated repository, (I’ll call this the “new working copy”).
- On the old working copy, do an
svn export. This gets you all of your most recent files, but without any .svn folders in the mix. - In Terminal copy the exported files into the new working copy by running the command
cp -R exported_folder/* new-working-copy-folder - [optional] Do an
svn infosvn statuson the new working copy. It should show that you need to check in all of the changes you made since the repository was last updated, (or since your last backup). - Commit the changes in your new working copy. You are finished, (you might want to archive the old working copy at this point in case something didn’t work right).
Your new repository should now have the latest work in it from your working copy. You will have lost the revision history between your latest backup and whatever you had in your working copy, but you won’t have lost it all, and you will once again be up and running and ready to code, (or write, or whatever).
Of course, you could avoid this whole hassle by making sure your backups are always up to date.
Svn info in your old working copy gives you the repository UUID which is différent from your new repository.
That is why were not allowed to commit to your new repository while the repo urls were identical
A svn relocate would probably sync the new repository UUID. But then, i don’t know how subversion would handle the commit of a higher revision.
The way I had my backups this time the UUID of my new repository was the same as the UUID of the old, (I just backed up the files on the SVN Server’s disk). However, if your backup is set up differently, (like, perhaps an
svnadmin dumpor something), then you’re right, the UUIDs won’t be identical and yes, you chould do ansvn sw --relocateor something like that to tell your working copy to use the new repository.We do, however, still end up with the problem of the gap in revision numbers, which subversion doesn’t like, it gives an error along the lines of “The previous revision could not be found.” I think this must be because it tries to do a diff from between the revision you’re committing and the previous revision that’s on the server.