0

This might be a repeated question from here (recreating svn repository), but I think I should ask this again.

I do not have a most recent back up of the repository but a month old backup. I have multiple working copies that are recent. Using the month old backup, trying update says that the revision does not exist as the repository is at a older rev.

What is the best option for me?

Do I start over creating a new repository? I lose all the svn history. But I would have to manually merge the two working copies. Can anyone please list the steps?

Or do I somehow use the month old backup recreate the svn repository. So that I have some history and lose history only for the last month. Not sure if this possible, but if it is please list the steps.

Any help is really appreciated. Thanks.

Community
  • 1

2 Answers2

2

Or do I somehow use the month old backup recreate the svn repository. So that I have some history and lose history only for the last month. Not sure if this possible, but if it is please list the steps.

That's the approach I would recommend. You'll be left with a repository that has all of the old history, and a single big commit that has the sum of all changes that occurred in the last month.

  1. Recover your backup from a month ago and set up your subversion server again.
  2. Check out a working copy from this recovered server. The contents will (obviously) be a month old. (We'll call this WC1)
  3. Go to one of the working copies that you had checked out from before your lost your server... the one that is most up to date. (We'll call this WC2)
  4. Manually move the files from your most recent working copy (WC2) into their corresponding location in WC1. Don't move directories, just files. If directories have been created, make them again using svn mkdir. If files have moved, move them with svn mv. In this step, you're essentially manually recreating the difference between your month-old backup, and your most recent working copy.
  5. When you think you've got it, use svn diff to double- and triple-check the giant commit.
  6. Commit the changes
  7. Delete the broken working copy, as all of the changes in it have been migrated back into the subversion repository on the server.
lukecyca
  • 2,205
  • 13
  • 20
  • The important reason behind "don't move directories" in step 4 is that you don't want to copy any `.svn` directories from the old WC, because that will put the new WC in an invalid state. – hobbs Oct 15 '09 at 22:14
0

I would be tempted to use git-svn to pull in the old repository. Then add any data you have any from your working copies, into your git repository. And finally, build a new clean svn repository and push everything in from git. Of course anyone using the repository will need to do a new checkout from the new repository.

My idea is that it would work somewhat similar to the process described here.

Zoredache
  • 130,897
  • 41
  • 276
  • 420