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