I'm managing a project that includes about a half a dozen developers and they have an existing SVN repo that most people have been using basically as a network share. PLEASE don't swamp me with all the "Well, they are just going to have to learn Subversion!" comments. I know what would be best but I'm trying to implement what is within the realm of possibility with this group and that means I can only expect them to learn just so much about Subversion at this time. Eventually I know they are all capable of learning the "right way" to do it, but right now I need a temporary solution to get us through a rough spot.
Any way, this "project" is actually composed of a few dozen different little "sub projects" from a source code control perspective because the "program" is actually collections of dozens of separate programs and reports that can all be worked on independently. I add this information to set the stage that, for a developer to work on a "piece" of the project, they can actually "check out" one sub project from the trunk and not actually have to grab (and subsequently merge) the entire trunk. Any way, they do have scenarios in which two or three programmers may be making changes to the source code for a single EXE in parallel. So they do end up with Merge/conflict resolution issues occasionally. I've looked over the documentation for the standard merge functionality in Subversion and I just can not see this group being able to get proficient with that process in the near future for a lot of different reasons. So, I'm considering implementing basically "manual merge" procedures and I'd like to run those by the folks in this forum to see if you see any MAJOR problems with this. What I'm considering as procedures is something like this: When a developer needs to work on a project in the trunk they would 1) create a "branch" directory in the repo with the name of the subproject, a dash and then their name 2) copy the sub project from trunk to that branch 3) check out the branch to a WC 4) make their changes, committing back to the branch as necessary If they need to "pull" changes that may have been made to that sub project in trunk (or even a colleague's branch of the same subproject for that matter) while they are working on the same sub project they would 1) check out a copy of the trunk (or colleague branch) copy of the sub project to a separate WC on their local machine 2) perform a manual DIFF/Merge with KDiff to incorporate changes from the trunk into the WC of their branch When it's time to integrate their changes into trunk 1) The program would commit their current branch WC back to the branch in the repo 2) A "code manager" would then check out that branch to one WC and check out the same sub project from the trunk to a separate WC 3) The code manager would then do a manual DIFF/Merge with KDiff, putting the "merged" results into the trunk WC 4) The code manager would then do testing and if the merged code passes testing 5) Commit the merged source files to the trunk 6) The developers branch folder in the repo would then be deleted. Does anyone see any major problems with this approach? My limited understanding of "merge" in SVN is that it basically does this same process, but automatically. The problems I have with the built in "merge" is, it seem a little confusing regarding the "source" and "destination" of the merges AND the requirement of having to select specific revisions numbers/ranges to merge, I think is going to be way too problematic in my environment. Thanks in advance for any advise. Tom Malia T <http://www.ttdsinc.com> &T Data Solutions L.L.C.