Re: [tlug] Open-source repository question

[Curt Sampson <cjs@example.com>]

On 2009-07-16 19:33 +0900 (Thu), Stephen J. Turnbull wrote:

> Edward Middleton writes:
> 
>  > Do any of the mercurial hosting services have anything equivalent
>  > to the github network graph visualizer[2]?
> 
> Not that I know of.  I don't know why Mercurial users would want one,
> to be frank; Mercurial itself strongly encourages linear development
> and rapid reconvergence to a handful (at most) number of branches.

Fascinating. I don't have the time, of course, but I definitely need to
check this out before proceeding much further with git.

In my world, we don't use branches much. Out of three dozen or so
projects we've got in our main svn repo, perhaps three have a branch or
tag.

I'd not thought about why we don't use branches much, but upon
reflection, two points come to mind.

First, branches are anti-social. They're a way of saying, "I can't work
closely with you, so I'm going to ignore you. They're also, to a lesser
degree, a way of avoiding responsibility: when you make a change that
breaks something over in another branch, you're saying that you don't
want to know about that and deal with it now, you want to leave it for
the merge (and perhaps whatever poor sod ends up doing it instead of
you).

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, and I don't kill the productivity
of other developers when doing so.

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.

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. They're also
the shortest branches; as soon as I merge any new changes and commit,
the branch is over. By that criterion, in our largest repo we've had
close to 12,000 branches in the last three years, or an average of ten
or so branches per day.

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.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com