I have an SVN repository set up like so:
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.
QA testing is complete, the
QA branch is merged to the
UAT branch, where
UAT is performed.
UAT is complete, the changes are merged to the
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
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).