How can I avoid editing conflicts repeatedly when merging from one to branch to another?

Question

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).

Answer 1

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.

Answer 2

Your problem is you aren't working on the same codebase. Each dev has their own codebase, which is apparently being allowed to diverge significantly from the trunk (if it wasn't diverging, you wouldn't have this problem).

I think the existence of the 'programmer' branches is really the problem here. You should probably go for per-project branches, and when you promote the change to the trunk, then you should either terminate the branch, or at least sync the trunk changes back onto the branch.

Doing that will keep the difference between the project branches and the trunk to a minimum, and minimize the issues when merging.

Another way to deal with this would be to have the programmers grab trunk changes onto their branches on a regular basis (daily would probably be best). This again will keep their branches as similar to the trunk as possible, again minimizing hassle during merge.