0

I migrated to a new subversion server but one of the working copies was still pointing to the old one. I have checked in over one hundred revisions and I don't want to lose my check-ins. I am going to answer this myself, but I think others may find it useful.

[Below added on 2014 February 18]

To be clear, since I was downvoted by someone who left no feedback and the question below seems to not understand the situation.

I had three different working copies pointing to a repository. I migrated the repository to a new server. Unfortunately, I pointed two of the working copies (directories) to the new server, and accidentally left one pointing to the old repository. I continued to check in source code. By the time I realized that this working copy was checking code into the wrong repository, there were over 100 check-ins to the WRONG repository and about 300 to the new repository. Not so hard to merge, except that one of the files had been renamed. Somehow, I managed to rename the file in BOTH repositories, so it was NOT just a matter of dumping 100 transactions from old repository and loading them into new repository. Only one of the rename events could be present. I chose to bypass the rename in the new repository, since that was the only transaction that I could find which involved this directory or files in it. I hope this clarifies the mess that I caused, and why it was tricky to clean up.

Bradley Slavik
  • 875
  • 7
  • 13
  • 1
    I don't understand the problem... you can't lose checkins from a working copy. you can simply do an svn switch --relocate to point the working copy at a the new location of the repository. – thekbb Feb 04 '14 at 15:31
  • thekbb: I do not understand your concern. I know I won't overwrite/lose the source code, but there is valuable information in my check-in comments. I needed to merge the two repositories. Also, it is not as simple to just point to new repository. You cannot just check out into the same directory. There is a directory called .svn there that needs to be adjusted to point to the new repository, or all the checksums for the files will be wrong. – Bradley Slavik Feb 04 '14 at 18:25

1 Answers1

0

There were some nice instructions for similar situations, but I could not find one for this disaster. I knew a reasonable amount about subversion before, now I know a lot more. First problem, the bifurcated repositories had a conflict. One file I had renamed, messed up the rename, and renamed it again in the next revision. I had also renamed it correctly in the other repository, so there was no chance that I would be able to just merge the repositories. Subversion made that very clear. I had to walk the original repository and find the offending revisions (1683, 1684). I was using the svnx GUI, so this was not too difficult. Here is the part that had to be precise. I had to dump the master repository in two pieces. Here is the code:

svnadmin dump MasterRepository -r 1:1682 > MasterRepository.svn.20140203_1.dump
svnadmin dump MasterRepository -r 1685:1751 --incremental > MasterRepository.svn.20140203_2.dump

Notice that the second dump is incremental. Maybe it could be done some other way, but this is the first thing that worked for me.

Next, dump just the revisions from the other repository which are since the split:

/usr/bin/svnadmin dump OtherDepository -r 1624:1721 --incremental > OtherDepository.dump

Now I need to move aside the original repository:

cd /Library/Server/Subversion
mv MasterRepository MasterRepository.old

Create the new repository on the server:

/usr/bin/svnadmin create MasterRepository

Load the three partial repositories, first the first dump of the Master, then the other two:

/usr/bin/svnadmin load MasterRepository < MasterRepository.svn.20140203_1.dump
/usr/bin/svnadmin load MasterRepository < OtherRepository.dump
/usr/bin/svnadmin load MasterRepository < MasterRepository.svn.20140203_2.dump

I still had problems with svnx not wanting to allow me to use my original directory as a working copy. I ended up moving it aside. Checking out a new version, and using tar to copy the old directory and paste it on top of the new directory.

tar cvf htdocs.tar htdocs
mv htdocs htdocs.old

(Here I used svnx to check out to working directory, which created directory, created .svn subdirectory, and copied all files in repository branch)

tar xvf htdocs.tar

Looking in svnx, the files which showed up as modified were exactly the right ones. There may be a more elegant way to accomplish this, but I am happy with the results.

Bradley Slavik
  • 875
  • 7
  • 13