On 9/23/13 1:04 PM, C M wrote:
> But coming back to my original question: Are there any potential gotchas with
> using a single/shared branch? For now, that's the only change the team (and
> leadership) is looking to as the "solution".
In my opinion there isn't a single answer to this question. Which strategy you
want to use is entirely situational.
If you're using a single shared trunk then you're going to run into situations
where you'll want to still use a branch because the work being done is
disruptive. The only alternative to that is to start adding flags in your
build system to hide this.
If you use branches often, then you'll still have changes where they are small
enough there's no need for the branch.
> Our developers code on a Unix like platform and have little SVN experience to
> boot. The idea of turning over merging to them seems to be a recipe for
> disaster. I would prefer to let the CM team handle the merges and figure out
> what I did incorrectly to mess up the previous merges.
In truth every commit is a merge (the HTTP method SVN uses for commit is
MERGE). Who better to be committing/merging than your developers?
Consider the following situation. Developer A and B are both working on a
project we'll call widgets. The code has the following layout.
widgets
widget/foo.c
widget/bar.c
widget/baz.c
main.c
Developer A starts modifying a function we'll call stamp(), let's pretend that
stamp controls the formatting of a date and serial number coding on the widgets
we're producing and lives in main.c. foo and bar widgets have this coding but
the baz widget is new and hasn't had it added yet. Developer A has been given
the task of adding a time code to the stamp. Developer A has an entire working
copy at revision 20.
Developer B is working on the baz widget and is now getting to the point of
adding the stamp and adds a call to stamp() to baz.c. He commits revision 21
doing so.
Developer A continues working against revision 20 has finished adding time to
stamp() and in the process adding a new argument to input the time to stamp.
He updated the calls in foo.c and bar.c but since he only has r20 he doesn't
see that widget/baz.c has added such a call. He commits his code in r22.
Now the baz widget has been broken. Subversion didn't complain because the
changes were in different files and don't appear to conflict.
Now consider if both developers had been working on branches. If they merge
their branches back to trunk in the same order then you'll have the same problem.
All branches do is delay the conflict and potentially limit the number of
people that are impacted by the conflict. In my opinion the further you get
from the creation of the conflict both in time and individuals the harder it is
going to be to fix it. But that also doesn't mean you should never use branches.
I really don't understand how CM doing merges helps avoid problems. The
developers are in the best position to understand the impacts of their merges
and deal with any conflicts (raised by Subversion or semantic and not shown as
a conflict by Subversion).
If you're uncomfortable with your developers knowledge of Subversion, you
should invest in them and spend the time improving that knowledge. It'll pay
off more than any change in branch strategies ever can, since as I demonstrated
above, both strategies can have the identical problem.
Received on 2013-09-24 02:14:34 CEST