Question

I did not use the hotcopy to back up my Subversion repository. We use Visual SVN Server (latest) with tortoise. I copied C:\Repositories and backed that up a few days ago and now I want to restore it.

I'm able to use the repository now with the backed up Repository folder copied over.

and then I guess now I have manually go through everyone's local project on the team to see who has the lates revision? If so that will take me hours.

anyone know if this is the right way or only way? Is it really this manual? I guess it would be because everyone has different changes locally.

Was it helpful?

Solution

How about this approach, each developer:

  1. Does an TortoiseSVN -> Export of their now invalid working copy to a temporary location
  2. Gets a fresh checkout from the restored repository
  3. Copies the exported working copy (i.e. no .svn dirs), over the top of the new working copy
  4. Update and commit as per usual

Note that you may get more merge conflicts than usual, but they can be resolved in the usual manner.

OTHER TIPS

Any changes that were made since the backup are not present in the repository, and everyone will have to do a fresh checkout from the restored repository. (The revision numbers have changed, and you'll have a mess if you don't.)

As for salvaging any changes from developer's local copies, yes, that's going to be rather manual. However, "diff" and "patch" are your friends. If you aren't familiar with cygwin, you'll want to get that and get the diff, patch, diffutils, and patchutils packages so you have the 'diff' command and the 'patch' command. You can use the "diff" command to create a file containing the delta between one copy of the source tree and another. You'll want to use it like this:

diff -urN --exclude=.svn fresh_check_from_new_repo old_working_copy > developer1changes.patch

Do that for each developer's working copy. You can take those files and apply the changes to a fresh checkout using the "patch" command like this:

cd working_copy
patch -p1 -i ...../developer1changes.patch

You will now have a working copy with their changes. (Though without their svn adds, svn rms, and property changes.) From there, determine what needs to be committed.

You can use the "filterdiff" command to take the patch file and filter portions of the changes out, pipe that to patch, and it will apply just those changes.

edit: Another option: for each developer, create a branch and checkout that branch, then copy their local copy over the files in that new working copy and commit.

That gets all the work in the repository where it won't get lost. You will then have to deal with conflicts when trying to merge the branches into trunk. At that point, you should be able to use the gui tools to select which changes to keep or toss.

But the short answer is: you've got a lot of work to do since you don't have a very recent backup of the repo... so once y'all are able to work again, setup a much more frequent backup schedule.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top