ansaurus

Question

Answer 1

A:

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 2010-10-21 08:42:41

That all sounds like a lot of pain, and I'm concerned about how traceable importing dumps is.

exception 2010-10-21 16:31:08

@exception: What do you mean, "traceable"?

sbi 2010-10-23 14:47:40

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 2010-10-24 18:17:58

@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 2010-10-24 19:09:34

...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 2010-10-24 19:11:25

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 2010-10-26 16:21:56

Answer 2

A:

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 2010-10-21 16:35:52

This turned out to result in too many conflicts unless I was very careful to select the range of changelists.

exception 2010-10-26 16:19:40

ansaurus

tags:

views:

answers:

Re-importing from CVS into Subversion

related questions