How to merge two seperate - yet similar - codebases into one SVN rep?

Question

Hi guys,

I have

/var/www/cool_codebase on www.example.com AND I have

/var/www/cool_codebase on www.example.net

The codebases are for the same web app running on different servers. There is some specialisation between the codebases (client-specific bits and bobs etc) - but not too much. One codebase has files that the other doesn't and vice-versa. Some bits of programming are different too.

I have downloaded each codebase to my localhost and my question is:

How can I merge these two folders into one folder and then commit it as one "grand unified codebase" into my SVN?

Should I put each codebase into its own SVN repo, and then merge these separate repos? Or can I merge the codebases before SVN - using some linux command for example - and then commit it to SVN?

Any ideas or help would be greatly appreciated.

I should add that the end result would be ONE "grand unified codebase" that we can deploy to both www.example.com and www.example.net with no hiccups.

(PS. Yes, I realise that whatever I do I'll have to edit some of the files and make the programming "generic" and so on. I don't mind this. I'm simply looking for ways to automate or semi-automate the whole thing.)

Answer 1

Merging the code bases after committing them to svn has the advantage that you have access to their history afterwards: You'll be able to see which parts of the code came from the ".com" version, which from the ".net", and what changes were made in the process of combining the two.

One way to do this:

1. Import the ".com" code base into a new repository as trunk.
2. Create a branch from that trunk: svn cp svn://repo/trunk svn://repo/branches/net
3. Check out the branch, copy in the ".net" code, do svn add and remove as needed so that the branch contains exactly the .net version. Commit that.
4. Check out the trunk and svn merge ^/branches/net .
5. Very carefully review the output of svn diff, and edit the trunk checkout so it becomes your grand unified codebase.

How difficult step 5 is will depend very much on the specific code bases.

If you happen to have access to an older "common ancestor" version, from which both of the code bases are derived, then you should check that version in at step 1 instead, and then check in the ".com" version to the trunk before step 4. This enables svn to do an automatic "3-way merge" at step 5, potentially saving you a bunch of manual work.

Whatever way you do it, some manual editing of files will be needed. That goes a lot easier with a good interactive merge tool, such as meld, which is also a great alternative to plain svn diff for step 5 above.

Note that meld has the ability to a) compare entire directory trees and b) compare and edit three versions at once. So you can point it at a a directory containing the ".com" code, one containing the ".net" code, and your working directory to see all three versions side by side.