Re: Source management tools for lilypond projects

[Colin Hall]

On Tue, May 22, 2012 at 10:26:02AM +0200, Urs Liska wrote:
> Dear Susan,
> 
> I think this makes sense (although I can't tell if it really is what
> Colin wanted to express ...).

It was pretty close. Thanks, Susan, you write well.

> Do I understand correctly that what you describe is one possible
> strategy to take care of the integrity of the main source tree?

Yes. Integrity in the sense that it passes (I'm guessing) these three
tests: no errors from Lilypond, the scores look good, and the midi
sounds fine.

> And another one would be what I have the impression is going on with
> LilyPond development: Every contributor can commit updates, but they
> are only merged to the main or master tree after some kind of review
> process?

Yes. 

> What I'm feeling slightly uneasy about with your suggestion is that
> it relies on some kind of 'lock' state. Nobody except the owner of
> the build token is allowed to update the master branch.

Yes, that's right. They are responsible for moving the head of the
master branch forward.

> This is only acceptable if it is somehow enforced by the system and
> doesn't rely on the reliability of the people involved.

You have to be able to rely on your team.

> And I feel this may lock up things if someone doesn't give back the
> token fast enough?

Yes. Susan's point about "small commits and often" is very important,
and more so as your project approaches a release date.

Traditionally, in a shared office, people use a rubber chicken or a
ball. You throw it to each other.

In distributed teams subject-only emails work well e.g.

From: Urs
Subj: I'm taking the build token

(Urs integrates new spacer rest layout)

From: Urs
Subj: Build token free.

(Rest of team do a git fetch or something like that)

From: Susan
Subj: Taking the build token

(Susan integrates new coda section)

etc etc

Cheers,
Colin.

-- 

Colin Hall