lilypond-user
[Top][All Lists]
Advanced

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

Re: Source management tools for lilypond projects


From: Colin Hall
Subject: Re: Source management tools for lilypond projects
Date: Tue, 22 May 2012 10:55:09 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, May 22, 2012 at 11:23:34AM +0200, Urs Liska wrote:
> 
> thanks for your patience. I somehow start to see some light ;-)

Good!

> Am 22.05.2012 10:53, schrieb Colin Hall:
> >On Tue, May 22, 2012 at 10:26:02AM +0200, Urs Liska wrote:
> > > 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 

Yes. Just use a simple check list.

> > 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.

I encourage you to use human to human communication. In fact just
phone me; I can explain it much better over the phone. UK office
hours.

> 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.

Perhaps.

You only have to coordinate development of things that will be the
result of a collaboration.

If only one person works on a given score, and only one person creates
the book of 26 scores, you don't have an integration problem.

> 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.

Correct. That's exactly where version control with branches helps. The
two authors work independently in their own branches to develop piano
and lyrics separately.

> 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.

Sure. Use version control.

If you are having trouble keeping a complete, working version
available, use integration management.

> I hope there are tools that address this situations with some 'smart
> merge' strategies ...

I suggest you take one of the scores that is either near completion or
just started and try using git on it. You'll soon get the idea.

Cheers,
Colin.

-- 

Colin Hall



reply via email to

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