On 8/10/2010 9:26 AM, Tom Malia wrote:
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.
That approach could work, but it (a) seems much more complicated than
simply dealing with an occasional conflict in the trunk and (b) tends to
isolate everyone instead of encouraging them to work together. Why not
make your 'code manager' a 'release manager' who copies known-good
versions of projects to branches and tags so you always have easy access
to working, released code. Then the trunk can be more of a free-for-all
where development happens and you can encourage developers to commit and
update often to minimize the scope of conflicts (and the wasted
conflicting work as well). With this approach you only need to merge if
you are supporting multiple released versions at once and have to back a
trunk change into an older version on a branch made earlier.
--
Les Mikesell
lesmikes...@gmail.com
