Subversion Merge between multiple working copies?

Question

We've completely lost our repository and we have 8 developers with uncomitted changes. Restoring from backup is assumed to be not possible.

If one person could have access to all the working copies (either file copy or remote share) is it possible to merge changes in our working copies to one working copy? The final working copy could then be imported into a new repo.

In short, can you merge two different working copies without the server?

edit: please don't poo poo me for not having backups; that part is beyond my control. It was assumed they were getting backed up nightly.

Followup: this is what we did:

1. Started with the most up to date working copy of all the developers.
2. Imported that into the new repo.
3. Working from newest working copy revision to oldest, copied in ONLY the files with changes then committed.
4. wash-rinse-repeat 6 times. (2 devs didn't have uncomitted changes).
5. exported all the old working copies, zipped them up and stored them for safe keeping if needed.
6. Updated our revisions in the release management database to the now very young repo.

Answer 1

Your problem is not that you have lost the server but the repo itself. Apart from re-creating a new repo and carefully sort the various working copies for import, I do not see what you could do. Good luck.

PS: bad on you to not having backups...

PPS: this is the sort of problem DVCS solve naturally by having for most of them a complete copy of the repo in every developer's sandbox.

Answer 2

The easiest way would be to create your own server, create a test repo, add one (most stable) build in it, and merge the working copies one at a time. But yes you lost all history because you lost your old repo.

You can then create you main repo from that test one.

Answer 3

I would try just picking one working copy off which to do an import for the new repo, and then repoint the remaining 7 working copies at that new repo using svn switch, possibly with relocate, to make them believe it's the same repo but relocated. Just try to pick a working copy for the initial import that has no (or as few as possible) structural changes from the lost repository: e.g. just file edits.

Of course, make tons of backups of your working copies in case the above doesn't work :)

Answer 4

Subversion keeps the original version of a file in the local working copy. Create a new repository, make a copy of the oldest working copy, revert changes on the COPY of the working copy, then import that working copy to your new repository.

svn import: http://svnbook.red-bean.com/en/1.0/re12.html

Once you've imported, you can use svn switch --relocate to repoint the other working copies to your new repository, and commit the changes.

svn switch --relocate: http://svnbook.red-bean.com/en/1.1/ch04s05.html

Answer 5

Hi tricky problem this one. But this is what I would do.

1. Create a new repository.
2. Create 8 branches and 1 trunk
3. Import the developers work on the branches.
   • Developer 1 on branch 1
   • Developer 2 on branch 2
   • etc etc
4. Then start to merge from branch 1 to trunk. And when you have a stable condition in the trunk, you continue with branch 2 etc etc

And when you are done with this horrible work, teach the developers about checkin early and often... And how to use branches...

/Johan

Answer 6

Since you lost your repository (sorry for that), you also lost the whole history.

All you can do now is start from scratch.

1. create a new repository
2. create the folder structure
3. export the working copy of the first user to a new folder
4. import the exported folder into the repository
5. all other users now check out a new working copy
6. all other users now 'export' their original working copy over the new working copy

by 'export', I mean creating a copy of the working copy, but without the hidden .svn folders in it.

Answer 7

Create a new repository in the same location as the old one from the most original working copy (That way you catch more history in the new repository).

If and where it doesn't work, put in .svn-directories from a checkout of the new repository. (For example checkout, and delete everything but the .svn-directories)