How bad would it be to use "nonstandard" merge techniques?

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.

 
Received on 2010-08-10 16:30:25 CEST