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
lesmikesell_at_gmail.com
Received on 2010-08-10 17:01:10 CEST