1

The problem I'm trying to solve is not dissimilar to Subversion out of sync with production code, easiest way to update subversion but somewhat different.

I converted a (Java) project from CVS to SVN (using cvs2svn, retaining full history) - say at version 1.00

Development on version 2.00 continued with the code in SVN.

Meanwhile, some fixes were done in CVS (as the dev tool setup was different.)

Now, what I need to do is effectively re-import part of the project from CVS.

If I had 

cvs:project/module1 (version 1.00)
           /module2 (version 1.10)

and 

svn:project/trunk/module1 (version 2.xx)
                 /module2 (Version 1.00)

Is there a way of just re-importing module2 from CVS and retain full history?

I've run cvs2svn again on the CVS repository, and was going to load that into SVN as another project, and then do a baseless merge - but I'm not sure if that is such a great idea.

I will be maintaining version 1.xx in SVN going forward.

Community
  • 1
  • 1
exception
  • 569
  • 7
  • 20

3 Answers3

0

You could convert the current CVS repo into a new dummy SVN repo. Using that, you could cherry-pick revisions to dump and replay those dumps back to the real SVN repo. (I have no idea how this would deal with the case where the same file was changed both in the real SVN and in the CVS/dummy SVN. You might want to avoid finding out about that by replaying the cherry-picked dumps to a specific branch.)

There might be better ways, though, and this might not work at all. I have only ever converted one CVS repo into a SVN repo and that was a pain-in-one-go task. So take this with a lot of salt and dry-run it on a copy first.

sbi
  • 219,715
  • 46
  • 258
  • 445
  • That all sounds like a lot of pain, and I'm concerned about how traceable importing dumps is. – exception Oct 21 '10 at 16:31
  • @exception: What do you mean, "traceable"? – sbi Oct 23 '10 at 14:47
  • Retaining history. I'm currently trying to consider either merging the specific change lists from V1.x that were made AFTER the original migration to SVN, or I might actually simply copy the whole module across. – exception Oct 24 '10 at 18:17
  • @exception: I now remember that, before the CVS-to-SVN transition was complete, some test project was started in a temporary SVN repo. As is usually the case with such toy projects, it outgrew its original intention and showed all signs of becoming the real thing. Since we didn't want to lose the history of it, rather than just adding an exported version of it to the SVN repo, we created a dump from the toy repo and imported that under a specific folder in the real SVN repo. I remember first trying in a sandbox. Not sure if everything was Ok right away, but it must have worked out easily... – sbi Oct 24 '10 at 19:09
  • ...because I don't remember there being any problems. It really grew into a full-blown project and is now installed at several customers'. And the history is all there, right to the first checkin, which originally took place in a different repo. – sbi Oct 24 '10 at 19:11
  • It was simply easier to delete the files and replace them by copying from the 2nd import. As that is staying in SVN it also has full history. It probably wasn't the most elegant solution, but it got the job done. I didn't really have time to try the dump method, but it's something I will experiment with for future use. – exception Oct 26 '10 at 16:21
0

Since I am going to maintain version 1.xx in SVN as well, and I know at what point the code diverged, I should be able to only merge the changelists created after the migration to SVN. This looks like it will keep things tidiest.

I'm experimenting with that at the moment.

exception
  • 569
  • 7
  • 20
  • This turned out to result in too many conflicts unless I was very careful to select the range of changelists. – exception Oct 26 '10 at 16:19
0

From the version numbers that you quote, it looks like all of the post-conversion commits on module1 were in Subversion and all of the post-conversion commits on module2 were in CVS. If that is the case, you might try the following:

Convert the entire CVS project again, using the same cvs2svn options as before. If you are lucky, r0:rN (where N is some number) of the resulting Subversion repository will agree with the overlapping part of the Subversion repository resulting from the first conversion. In this case, you should be able to "svnadmin dump --incremental -rN:HEAD" from the new Subversion repository and "svnadmin load" it on top of the old Subversion repository. The commits in the combined repository will not be in chronological order, but that is a minor annoyance (and could possibly be fixed using some other tools at the expense of renumbering the Subversion commits).

(It is not necessarily the case that the overlapping parts of the Subversion repositories will be identical; cvs2svn uses some heuristics to deduce changesets and their deductions could differ because of other changes. But as long as there are identifiable "1.00" revisions in each repository with identical contents, then I think the procedure should work.)

Make backups before you try this!

mhagger
  • 2,687
  • 18
  • 13