Version Control Merging – How to Avoid Editing Conflicts When Merging Branches?

mergingorganizationsvnversion control

I have an SVN repository set up like so:

trunk
branches
- UAT
- QA
- DevelopmentTeam
- programmer1
- projectA
- projectB
- programmer2
- projectC
- projectD
- programmer3
- projectE
- projectF
- projectG
- projectH

Each programmer can have multiple projects which are branches, and can be merged to their "programmer" branch.

All programmers branches are merged to the DevelopmentTeam branch by the Manager, where the changes are tested with other programmers' projects.

Once this testing is complete, the DevelopmentTeam branch is merged to the QA branch, where QA testing is performed.

Once QA testing is complete, the QA branch is merged to the UAT branch, where UAT is performed.

Once UAT is complete, the changes are merged to the trunk.

Now, let's say I have one programmer working on two project branches. They complete them on the same day, and each is merged to the DevelopmentTeam branch, then QA, then UAT. However, during UAT, it is discovered that some changes are needed. So the programmer goes back to his project branch, makes the changes, commits, then the merging up the line begins again. The problem is, that the new "conflicts" have to be managed at each merge.

I've used SVN for several years, so I understand branching, tags, merging, commits, etc.. But, I think I need a lesson in "organizing" (for lack of a better term).

Note developers are working in separate branches instead of shared (aka "unstable") trunk because I'm trying to setup a system where the trunk exists as the "production" code base. Anything in the trunk is considered "live". Then the Dev, QA, and UAT branches are for each level of testing (QA is the QA website, UAT is the UAT website).

Best Answer

Conflicts occur because two people change the same part of the code in different, incompatible ways. If you see a lot of them, this should raise some questions about your basic development methodology.

First, you appear to be abusing branching rather severely. Giving every developer their own repository basically defeats the purpose of having a collaborative version control system in the first place. (Yes, you still have the advantages of keeping a history and a "time machine" that you can roll back to, but that's only half the point of a VCS when you have a development team.)

Your project ought to be branched by version--a 3.0 branch, a 3.1 branch, a 3.2 branch, and so on--not by developer. When you need a stable revision of a version for a release, turn it into a Tag.

Having your developers all check in to the same branch (and synchronize frequently) minimizes the number of merge conflicts you run into, because having a shorter interval between merges means that it's less likely that two developers will touch the same code without synchronizing.

Also, try to assign specific areas of the codebase to specific developers. Again, this cuts down on the number of times their changes will overlap, which cuts down on merge conflicts.

Related Solutions

Version Control – Creating a Version Control Strategy for SVN

If you want a unified build process, then be sure to put branches/tags/trunk at the root, like this:

branches/
tags/
trunk/
  dev/
    ...

If you don't need a unified build process, then you can put branches/tags/trunks within each project if you want. However, it might be difficult to migrate to a unified build after having put them within each project. A unified build has advantages, such as eliminating the need to publish shared components among projects -- they're all part of the build.

Personally, I like a unified build process. Furthermore, I don't think you should have a "dev" project. You should have projects directly under trunk, and then branch trunk into a dev branch. Use tags for releases. For example, I would do it like this:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

Version Control – Maintaining SVN History During Merges

Unfortunately this is not supported directly by Subversion prior to Subversion 1.8. The files in the branch and the files in trunk are copies and Subversion keeps track with svn log only for specific files, not across branches.

So the only option is to filter your SVN log. The major downside to this is that in case you filter for file name, files being moved or copied to another name are not matched.

Subversion 1.7 and lower

To keep it practical I would get the history of the file you are interested in for your trunk

svn log http://www.your.org/svn/repo/trunk/path/to/file.txt -g

This includes the mergeinfo for your file like this:

Commit message
Merged via: r6504, r6493, r6451, r6429

Now you can see where the file comes from and then look up those revisions on your repository root with

svn log http://www.your.org/svn/repo -r 6504

Subversion 1.8 and higher

The Subversion 1.8 release contains a couple of improvements to the command line client that make the above easier. To find all log entries for a specific file you can simply search for it directly:

 svn log -v --search "src/foo.c" http://svn.example.com/svn/