Tag: working copy

How to Update an Outdated Subversion Repository from a Working Copy

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:

  1. In your existing working copy, (I’ll call this the “old working copy” from now on), make sure that you’ve done an svn add for any files that are not yet under version control but you want to make the transfer.
  2. Check out a new working copy from the outdated repository, (I’ll call this the “new working copy”).
  3. 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.
  4. In Terminal copy the exported files into the new working copy by running the command cp -R exported_folder/* new-working-copy-folder
  5. [optional] Do an svn infosvn status on 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).
  6. 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.