Reputation: 5003
I'm trying to merge multiple source repositories together, maintaining version history during the process. I've been doing a lot of reading on the svnadmin dump/load process, but there's one piece that I'm still missing.
Each source repository is setup with your standard "trunk" and "branches" setup. That's all good. The problem is that I want to massage the paths when I merge things together. For instance...
Many of the approaches that I've seen would allow you to create a structure this this:
/project1
/project1/trunk
/project1/trunk/html
/project1/branches
/project2
/project2/trunk
/project2/trunk/html
/project2/branches
However, I want our final structure to be like this instead:
/trunk
/trunk/project1
/trunk/project1/html
/trunk/project2
/trunk/project2/html
/branches
Reason being: All of the projects are intertwined. Project1 might be our backend software, project2 our front-end software, project3 our cron jobs, etc. Basically, it's all one combined system, and project specific branching seems to just make our life more difficult.
That said, the problem arises with how I translate the old directory structure to the new. Thoughts?
Upvotes: 0
Views: 261
Reputation: 40760
It may meet your needs to merge the repositories as is, with separate branching, then to move things around in the new, merged repo so that the latest revision has the files where you want them. This is less work than trying to edit history and you still preserve your history, although you may need to turn on showing history after copy. You then get your preferred structure for new revisions, even if checking out old revisions puts things in the wrong place.
Upvotes: 2
Reputation: 11908
The way I would do it is by preparing the "new" structure up front with normal svn move
and svn copy
commands and do the dump & load afterwards.
Trying to massage the dump file with svndumpfilter
in a format that fits your new repository is complicated and error prone.
Upvotes: 2