[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Developer branches

From: Steve Greenland
Subject: Re: Developer branches
Date: Wed, 6 Feb 2002 10:51:21 -0600
User-agent: Mutt/1.2.5i

On Wed, Feb 06, 2002 at 06:20:16AM -0800, Mark wrote:
> [Lot's of good stuff, up until:]
> Branches are for parallel development (ie. conflicting software
> requirements/functionality) not for resolving/preventing compile
> issues or isolating developers work so their changes won't impact
> others changes, as doing so merely delays and componds what you
> created the branches to avoid.

I'll disagree with this, somewhat: in particular the "or isolating
developers so that there changes won't impact other's changes".
"Parallel development" is useful not only for conflicting functionality,
but also changes that have broad but limited impact. That sounds like
an oxymoron, but what I mean is a change that involves editing a lot
of files, but in a way that doesn't necessarily conflict (on a textual
basis[1]) with other concurrent development. It may result in the build
being broken (either compiler time or run/test time) for a long while,
and if you don't branch, you have two possibilities:

1. The developer doing the big change does commits.
2. The developer doesn't do commits. 

For case 1, everybody else is screwed. No good. For case 2, the
developer is screwed, because she can't use CVS for her own work, and
thus is left with foo.c.20020131, foo.c.good, foo.c.orig sitting around
in her sandbox. Testing on other platforms is painful, because you have
to copy stuff by hand (always forgetting parts of it, and wasting time
re-inventing fixes), rather just going to the other box and doing a 'cvs
update -r branch_tag'. I'm sure that others here can come up with more

Neither choice is satisfactory. Branching requires more
work/responsibility on the part of the developers on the branch, and on
the release manager (or whatever you call the person responsible for
managing your repository). Therefore, one needs to decide whether the
extra work is justified by the benefits of branching in each instance.

The key point, I think, is that you can't, in general, avoid the effort
of merging and resolving conflicts. What branches can give you is the
ability to control when that effort has to be made. While mostly (I
think) the best answer to "when?" is "now", sometimes it's better to
delay it.


[1] If it conflicts semantically, then it wasn't designed correctly, but
that kind of issue is independent of branching choices.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]