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