Re: [tlug] Open-source repository question

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > First, branches are anti-social. They're a way of saying, "I can't work
 > closely with you,

That's not anti-social in my case, it's a physical fact.  My
colleagues don't want to move to Japan, and very few of them are free
to work on XEmacs whenever I feel like working on XEmacs (and
vice-versa), anyway.

 > They're also, to a lesser degree, a way of avoiding responsibility:

My colleagues have a better way of avoiding responsibility: they
commit to the mainline, then start studying for entrance exams to
medical school. :-/

I really don't think what you're saying flies, Curt.  What works for
you, works for you.  But I don't think "lack of branches" has much to
do with it, and for most open source projects, trying to run a tight
ship the way you do at work would result in all the developers
leaving, even if the flip side is being allowed to commit to trunk.

 > Some developers will claim that for major changes that touch things
 > everywhere in the system, when other people are also working on
 > things, branches are essential. That's rubbish. I do those sorts of
 > changes on a regular basis, I do them on the head,

I read manga on the head, myself.  Seems a little risky to use an
electric appliance that close to water....

 > and I don't kill the productivity of other developers when doing
 > so.

You also obviously get things right on the first try, every time, and
never need more than a day to finish a task.

That's not true of most developers.  In large-scale projects, the
advice is "build one to throw away, because you *will* throw away the
first effort."  Branches make that *much* less painful, not least
because of the possibility of cherry-picking or restarting halfway
through the branch.

 > Second, branches are expensive. Some VCSs may make it "cheap" to
 > create branches, but there is no such thing as cheap merging: the
 > cost of merging always goes up more than linearly with the size of
 > the change.  Working on a branch is like paying for something on a
 > credit card: if you don't pay it off real quick (i.e., merge back
 > to trunk), you're going to pay a lot more later.

All cowboy hackers say that, though, and they all use that to justify
their insistence on getting the right to commit to trunk.  The above
snide remarks not withstanding, I don't think you're in that class, so
something else is going on in your shop.  It's not just that it's
cheaper for you because you've eliminated merging overhead by doing
everything on the trunk.

Also, just because you're on a branch doesn't mean you can't merge
frequently *from* the trunk.  In fact, that was one of Tom Lord's main
motivations for developing Arch: he wanted a VCS that allowed
bidirectional merging.  The problem with CVS (and Subversion) is that
once you've branched, you have to stay on the branch until you merge
back to mainline.

 > I like to think of my VCS as providing the cheapest branches of all.
 > After I update, the first edit of a file creates a branch.

Indeed.  That is exactly the philosophy that led to git.  Every edit
is a branch, and the more of that you record, the more of the merging
can be delegated to the VCS.  Thus every VCS action needs to be cheap.

 > So now you know. When someone starts saying otherwise, they're not
 > saying that it can't be done. They're just saying that they can't
 > do it.

And when you say you can do it, you're also saying "when I'm boss, I
can do anything."  Well, where I live, we don' need no steenkin'
bosses.  People have different goals, and they want to work on the
code *now*.  Branches can help with the compromises needed in such
environments.