Re: Source management tools for lilypond projects

[Urs Liska]

Hi Colin,

thanks for your patience. I somehow start to see some light ;-)

Am 22.05.2012 10:53, schrieb 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.
Or anything else one agrees upon (for example, we don't care about midi 
in this case)
> > 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.
But it should be quite easy to implement mechanisms that enforce this 
(basically similar to lockfiles)
> > 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
Or maybe an empty file in some directory.
If the directory is empty I do
touch token_Urs
After doing changes I remove the file.

Maybe also possible with more fine-grained control in subdirectories (in 
the current projects we have a book with 26 individual scores. So it's 
only necessary to 'lock' one score at the same time, not the whole project.

What probably wouldn't work this way to have even more finegrained control.
For example if a) is working on the polyphony in the piano right hand 
file b) can without problems proof-read the lyrics in another file of 
the same score.
If we'd use the 'build token' concept (be it through empty emails or 
'lock files') then we're basically where we are right now (with a shared 
folder): tell the others which file I'm going to edit and ask them to 
leave this alone for a while.
I hope there are tools that address this situations with some 'smart 
merge' strategies ...

Best
Urs
> Cheers,
> Colin.