How to Merge Two Seperate - Yet Similar - Codebases into One Svn Rep

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

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.

How do I handle two separate yet very similar code-bases with git /github?

This can easily be done with two branches. I'm not sure why you say "code modified in one, cant easily and selectively be merged over to other," because merging is quite easy in Git.

The structure I would suggest is to have a branch for your general version and a branch for your personal version. Merges should only ever happen in one direction, from the general branch to the personal branch. This means that any changes you make to the general version get incorporated into the personal version.

In other words, this is OK...

git checkout personal
git merge general

This you should never do...

git checkout general
git merge personal

If you make a change in your personal version, and decide that it would be spiffy to have that same code in the general version, you should be able to handle this fairly easily with a cherry pick. It will just take a little forethought to organize the commits in the personal branch. You will need a commit in the personal branch that contains only those changes you want to bring over to the general version, then simply cherry pick it off the personal branch and drop it onto the general branch.

Two repositories can accomplish the same thing. This would reduce the risk of you accidentally uploading your personal version to Github, but it would make it more tedious to work with the two different versions.

Personally, I would go with two branches in the same repo.

Merge without Branching from the same code-base?

It is best if the two branches have the same starting point.

You can "merge" two unrelated branches in SVN (section "Merges Without Mergeinfo"):

Merging unrelated sources

If you ask svn merge to compare two URLs that aren't related to each other, a patch will still be generated and applied to your working copy, but no merging metadata will be created. There's no common history between the two sources, and future “smart” merges depend on that common history.

Note that this a situation where git would be more efficient, since it easy to setup two branches, each starting with "copyA", and erase the content of the second branch with "copyB" (git would detect all the renames, moves and additions introduced by "copyB" compared to "copyA").

If if you had created two unrelated branches in git, you would still be able to fake a common history and merge them.

SVN How to Merge Branch Twice

When you merge a feature branch to the staging branch, the feature branch remains unchanged. The changes are committed to the staging branch, including svn:mergeinfo property that tracks what is merged to the staging. But for the feature branch itself it is a completely read-only operation.

So nothing should stop you from merging the feature branch to the trunk too.

Have you tried that? Do you experience any errors?

How can I merge my files when the folder structure has changed

I'm in the same situation where branches aren't always just maintenance related nor hotfix related. We often have to maintain multiple active stabilization branches and must merge between them. We don't have the luxury of mixing scope to practice continuous integration on a trunk.

We resort to performing merges at a more granular level. If a folder is moved, perform the merge directly from the old location in one branch to the new location in the other branch. I'd also highly recommend that you use the "svn move" to do the original restructure, it ensures ancestry is understood.

Either way, it's not pleasant and very manual. Keep good records.

How would you plan for merging multiple branches?

If you want to have smooth merge, you should make sure you include base versions for each merge into the version control system, if you have those. Just determine that one of the branches that people most branched from is a trunk and then you need to record a version on the trunk for every time someone branched from it, if you have those. Without those base versions the merges will become a mess.

If there was no version control, not even someone doing a tarball of the code at the time they merged, so you cannot reconstruct even as little as the base versions, you will need to be very careful. Put the code into the source control prior to merging anything. Try to reconstruct the branches in as approximate way as possible by what has been branched from where.

Now if your source control system records merge links between branches and keeps a good track of base versions and merges, like for example ClearCase, you want to start from smaller merges, which can be done by individual developers to reduce the work in parallel first. Then do the large merges with all developers involved.

If on the other hand you don't have good tracking, changes from the already done merges will pop out again in the subsequent merges and you might need to redecide the conflicts again. This is quite painful so I would suggest to large merges with full team so everyone can see what has been decided and then they can keep the correct code during their smaller merges.

The main point is that without proper merge tracking, your need for someone who understands the code to be present or doing the merge increases, because he needs to identify the correct (current) chunks of code to go into the file.

Multiple SVN repos, update from one commit to other

Contrary to previous answers

Pure SVN-way for workflow

With Sacling WC

svn up
svn relocate ProdSVN
svn ci
svn relocate LocalSVN

Without Sacling WC

If direct comminication LocalSVN -> ProdSVN will be possible, SaclingCodebase can be excluded from sync process (less chains, less errors):

• svnsync (docs or blog posts one or two)

or

• svnadmin hotcopy + scp (?)

or

• Mirror SVN Repository [Write-through proxying] topic here

---

Related Topics