Removing initial Bar spanning two-staff system
I'd like to remove the initial Bar line that spans a two-staff ChoirStaff. How is this accomplished? Best i could come up with was: \override ChoirStaff.SpanBar #'transparent = ##t, but no luck. Thx, Javier___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \autochange between "treble^8" and treble
Am 22.05.2012 01:49, schrieb Jonghyun Kim: Dear List, How to do the "\autochange" between the "treble^8" and treble? Default setting is treble and bass Clefs, but I want to modify that. I want to display that: (download link) http://dl.dropbox.com/u/8142442/lilypond-user%40gnu.org/between%20treble%20and%20treble%5E8.gif sorry I can't ell you more than to look at http://lilypond.org/doc/v2.15/Documentation/notation-big-page#changing-staff-automatically and possibly middleCposition Eluze ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
New issue of The LilyPond Report! (#26)
Never before in the history of The LilyPond Report so many new editors appeared in so short a time! This month Pavel Roskin joins us to tell a story of wit and patience about a brave contributor who sets out on a quest to find the cause of strange LilyPond errors appearing out of nowhere. In other news, 2.16 stable release is drawing nearer and nearer: on this occasion David Kastrup shares with us some thoughts about our development process. Finally, a fundamental question is asked: is LilyPond output good enough? Have we managed to match the beauty of hand-engraved scores, or is there still a lot of work ahead of us? Read the newest issue of The LilyPond Report at http://news.lilynet.net/?The-LilyPond-Report-26 to find out, and don't hesitate to pass the link around! cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TupletNumber regression
John David Duncan-3 wrote: > > Hi, > > I have an example where 2.15.38 does a worse job than 2.14.2 at > placing a TupletNumber. > > I suspect it's related to a forced \stemUp, because the number might > be in the right place if the stem were going down. > > How should I submit my example ... in email here? In an issue reporter? > if it's a question about how to use a function ask in the user list; if you are sure it's a bug post it to the bug list. without your example I can't tell you more! Eluze -- View this message in context: http://old.nabble.com/TupletNumber-regression-tp33889961p33892712.html Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Source management tools for lilypond projects
On Tue, May 22, 2012 at 11:47 PM, Urs Liska wrote: > What I will have to see in action before really being able to believe it > works in 'real life' is the merging of text files that have been changed by > more than one person. Of course it's clear that it _must_ work (everything > what I might have in mind with such a system is of magnitudes smaller than > any average software project). But it's just hard to imagine ;-) The best part is that if the changes happened in distant places of the file, you won't have to do anything - it happens automatically :) cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Source management tools for lilypond projects
Dear Susan,
thank you very much for taking so much of your valuable time.
It's astonishing - like reading a good book, but one written with my
specific questions in mind :-)
Well basically everything really is very much what I had expected it to be.
What I will have to see in action before really being able to believe it
works in 'real life' is the merging of text files that have been changed
by more than one person. Of course it's clear that it _must_ work
(everything what I might have in mind with such a system is of
magnitudes smaller than any average software project). But it's just
hard to imagine ;-)
Best
Urs
Am 22.05.2012 12:22, schrieb Susan Dittmar:
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.
It looks similar, but there are big differences! You do not tell them to
leave the file alone, just to not finalize their changes with this file
yet. Every one can continue to work on his part of the things even when
another does wear the master head at that moment. What you are telling by
"locking" is not "do not touch", but "do not update from that" and thus
"do not finalize".
Let me try to explain.
Let's say, A and B are both working on one file. A works on the lyrics, B
works on the polyphony (just let's assume both are in the same file).
In his local copy, A can make as many changes as he wants, and all is fine.
In his local branch, he can even do as many checkins as he wants, still all
is fine.
At the same time, B an do as many changes to *the same* file locally as she
wants. In her local branch, she can do as many checkins as she wants, too.
Now A thinks all is fine with the lyrics. He now tells the group "I will do
an official checkin to the file now". From now on, *the main branch of the
file* is his to work on. He tells the repository program to merge his local
changes to the main stuff. As the main stuff is still the same as when he
created his local branch, all should work well. He does the necessary
consistency checks (like "compiles" and "looks well"), does (if necessary)
a final checkin to the main branch, then tells the group "file is free
again".
Remember, B was working on the same file. Even while A does his release and
locks the file, B gladly continues her work on the polyphony (and thus on
the very file A did lock!). Now, some time later, B finally is content with
the results and could check them in.
First she checks whether someone is holding a lock over the file. As A
already did his final commit, none does, so B can continue. She tells the
group (more on that later) that now she is wearing the master hat for that
file.
Next she tells the repository software to update *her local copy* with the
changes commited to the main trunk in the time between her checkout (the
moment she started to work on the file) and now.
This is the crucial point in which repository programs are such a help: A
and B did simultaneously *work* on the same file, and just the *checkin*
needs to be one after the other!
As A did change the file, the update will change B's copy. Usually, those
changes can be done by the repository software without problems. But if
A's changes and B's changes are too close together (like in the same line),
the software cannot tell which change will have to be kept, and will now
ask B about that.
After these clashes are solved, B has to do all the consistency checks
again. All was well with her changes before she did the update, but maybe
now she has do add some tweaks again.
B goes on making sure the file becomes consistent with policy ("compiles",
"looks well", ...) again.
Then B makes her final checkin, and gives back this file's rubber chicken
for the next one to grab.
How this rubber chicken mechanism is implemented depends on your group,
your requirements (what needs to work after a checkin?), and the software
you use. My approach with the branches would allow you to leave all the
locking and communication to the software. You create your branch at the
moment you start to work on a file, work within that branch until you think
all is well, update this branch from the main trunk to incorporate other's
changes, check integrity again (repeat update/check until there's only very
short time since last update), then commit your changes to the main trunk,
check consistency again to make sure (and correct immediately if needed),
and then forget about the branch afterwards. Only the time between your
committing to the main trunk and the moment you are sure consistency is
still obtained is time where others cannot be asured a newly checked out
version will work fine. This is the only time you might want to 'lock' a
file or even the whole thing.
For all this, no direct communication is necessary, just the discipline to
only make checkins to the main branch only wh
Re: \shape can crash Lilypond
Thank you very much! Seems to work perfectly (so far - until we find something new ;-) ) Best Urs Am 22.05.2012 17:28, schrieb David Nalesnik: Hi again, The problem happens when the variable "function" attempts to look up the procedure for 'control-points. Each override you do is tacked onto the front of the alist and so the key we're looking for-- 'control-points -- is pushed further back. You can see what I mean by changing cdr in the assignment for function (line 20?) to cddr for one override, cdddr for two overrides... This will "fix" the problem--provided the overrides come after \shape ... (The reason why cdr is used in the first place is that the current override of 'control-points would be there at the head of the list, and you'd get "calculation-in-progress" instead of ly:slur::calc-control-points or whatever.) I'll think about how to fix this and get back to you. Thank you for noticing this!! OK, the solution is pretty straightforward: simply replace (function (assoc-get 'control-points (cdr (ly:grob-basic-properties grob with (function (assoc-get 'control-points (reverse (ly:grob-basic-properties grob Crisis averted! :) -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Jazz chords
On 05/22/2012 04:57 PM, Choan Gálvez wrote:
On 5/22/12 16:53 , rosea.grammostola wrote:
On 05/22/2012 12:47 AM, lilyp...@umpquanet.com wrote:
On Mon, May 21, 2012 at 05:51:25PM +0200, rosea.grammostola wrote:
Hi,
What is the status of this?
http://lists.gnu.org/archive/html/lilypond-user/2011-11/msg00285.html
What do you mean by 'status'? It works for me. I've tweaked the
markup to suit my tastes, and have added some additional chord
structures, enough to regard it as a very functional and useful
framework.
I'm searching for a way to display A7(#5)
If you mean the markup, first find your jazz-chords.ily file and
make a backup. Then find the line inside 'jazzChordsMusic' that
reads:
-\markup\jcRaise{ "+7" }
Change that to:
%-\markup\jcRaise{ "+7" }
-\markup\jcRaise{ "7(" \jcSharp "5)" }
For the same chord, but minor, I changed this:
%-\markup\jcRaise{ {\larger\larger #(ly:export
(ly:wide-char->utf-8 #x00f8)) } "7" }
to
-\markup{ \jcMinor\jcRaise{ "7(" \jcFlat "5)" } }
Please tell me if this is wrong :)
\r
Thanks, that works! :)
Another case is the in a bar there is one optional chord diplayed like:
(D7)
See
or a case that an other chord is placed above the 'default' chord, like
(G7(#11)) placed above B7(b5)
You can use a parallel ChordNames context.
Best.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \shape can crash Lilypond
Hi again, The problem happens when the variable "function" attempts to look up the > procedure for 'control-points. Each override you do is tacked onto the > front of the alist and so the key we're looking for-- 'control-points -- is > pushed further back. You can see what I mean by changing cdr in the > assignment for function (line 20?) to cddr for one override, cdddr for two > overrides... This will "fix" the problem--provided the overrides come > after \shape ... (The reason why cdr is used in the first place is that the > current override of 'control-points would be there at the head of the list, > and you'd get "calculation-in-progress" instead of > ly:slur::calc-control-points or whatever.) I'll think about how to fix > this and get back to you. > > Thank you for noticing this!! > OK, the solution is pretty straightforward: simply replace (function (assoc-get 'control-points (cdr (ly:grob-basic-properties grob with (function (assoc-get 'control-points (reverse (ly:grob-basic-properties grob Crisis averted! :) -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Jazz chords
On 05/22/2012 04:57 PM, Choan Gálvez wrote:
On 5/22/12 16:53 , rosea.grammostola wrote:
On 05/22/2012 12:47 AM, lilyp...@umpquanet.com wrote:
On Mon, May 21, 2012 at 05:51:25PM +0200, rosea.grammostola wrote:
Hi,
What is the status of this?
http://lists.gnu.org/archive/html/lilypond-user/2011-11/msg00285.html
What do you mean by 'status'? It works for me. I've tweaked the
markup to suit my tastes, and have added some additional chord
structures, enough to regard it as a very functional and useful
framework.
I'm searching for a way to display A7(#5)
If you mean the markup, first find your jazz-chords.ily file and
make a backup. Then find the line inside 'jazzChordsMusic' that
reads:
-\markup\jcRaise{ "+7" }
Change that to:
%-\markup\jcRaise{ "+7" }
-\markup\jcRaise{ "7(" \jcSharp "5)" }
Thanks, that works! :)
Another case is the in a bar there is one optional chord diplayed like:
(D7)
See
So I have to put:
besideCN = #(define-music-function (parser location which-side
added-text) (integer? string?) #{\once \override ChordNames.ChordName
#'stencil = #(lambda (grob) (ly:grob-set-property! grob 'text (markup
#:put-adjacent 0 $which-side ; #LEFT or #RIGHT (ly:grob-property grob
'text) $added-text)) (ly:text-interface::print grob)) #})
In top of the ly file? That doesn't seems to work. All the text is
turned red. Missing bracket or something?
or a case that an other chord is placed above the 'default' chord, like
(G7(#11)) placed above B7(b5)
You can use a parallel ChordNames context.
Best.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
TupletNumber regression
Hi, I have an example where 2.15.38 does a worse job than 2.14.2 at placing a TupletNumber. I suspect it's related to a forced \stemUp, because the number might be in the right place if the stem were going down. How should I submit my example ... in email here? In an issue reporter? Thanks, JD ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Jazz chords
On 5/22/12 16:53 , rosea.grammostola wrote:
On 05/22/2012 12:47 AM, lilyp...@umpquanet.com wrote:
On Mon, May 21, 2012 at 05:51:25PM +0200, rosea.grammostola wrote:
Hi,
What is the status of this?
http://lists.gnu.org/archive/html/lilypond-user/2011-11/msg00285.html
What do you mean by 'status'? It works for me. I've tweaked the
markup to suit my tastes, and have added some additional chord
structures, enough to regard it as a very functional and useful
framework.
I'm searching for a way to display A7(#5)
If you mean the markup, first find your jazz-chords.ily file and
make a backup. Then find the line inside 'jazzChordsMusic' that
reads:
-\markup\jcRaise{ "+7" }
Change that to:
%-\markup\jcRaise{ "+7" }
-\markup\jcRaise{ "7(" \jcSharp "5)" }
Thanks, that works! :)
Another case is the in a bar there is one optional chord diplayed like:
(D7)
See
or a case that an other chord is placed above the 'default' chord, like
(G7(#11)) placed above B7(b5)
You can use a parallel ChordNames context.
Best.
--
Choan Gálvez
Re: Jazz chords
On 05/22/2012 12:47 AM, lilyp...@umpquanet.com wrote:
On Mon, May 21, 2012 at 05:51:25PM +0200, rosea.grammostola wrote:
Hi,
What is the status of this?
http://lists.gnu.org/archive/html/lilypond-user/2011-11/msg00285.html
What do you mean by 'status'? It works for me. I've tweaked the
markup to suit my tastes, and have added some additional chord
structures, enough to regard it as a very functional and useful
framework.
I'm searching for a way to display A7(#5)
If you mean the markup, first find your jazz-chords.ily file and
make a backup. Then find the line inside 'jazzChordsMusic' that
reads:
-\markup\jcRaise{ "+7" }
Change that to:
%-\markup\jcRaise{ "+7" }
-\markup\jcRaise{ "7(" \jcSharp "5)" }
Thanks, that works! :)
Another case is the in a bar there is one optional chord diplayed like: (D7)
or a case that an other chord is placed above the 'default' chord, like
(G7(#11)) placed above B7(b5)
Are there solutions for these cases?
Thanks in advance,
\r
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \shape can crash Lilypond
Hi Urs, On Tue, May 22, 2012 at 9:07 AM, Urs Liska wrote: > Hi David N, > > Recently we experienced strange crashes in our Lilypond scores that could > only be avoided by randomly changing the order of some function calls. > > Now I sat down and pinned it down quite narrowly: > If I use your wonderful \shape function and afterwards override any > property of the same grob it causes Lilypond to crash while 'creating > systems'. > Attached you'll find a file with detailed observations. > My impression is that your function somehow messes up with the grob's > variable/pointer or whatever, making a copy and not telling Lilypond or > such kind of thing. > > Anyone an idea what could be wrong here? > > It doesn't make the function unusable (not at all), but it can cause very > dubious errors that might be very hard to track (depending on the > situation). > > The problem happens when the variable "function" attempts to look up the procedure for 'control-points. Each override you do is tacked onto the front of the alist and so the key we're looking for-- 'control-points -- is pushed further back. You can see what I mean by changing cdr in the assignment for function (line 20?) to cddr for one override, cdddr for two overrides... This will "fix" the problem--provided the overrides come after \shape ... (The reason why cdr is used in the first place is that the current override of 'control-points would be there at the head of the list, and you'd get "calculation-in-progress" instead of ly:slur::calc-control-points or whatever.) I'll think about how to fix this and get back to you. Thank you for noticing this!! -David > Best > Urs > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
\shape can crash Lilypond
Hi David N, Recently we experienced strange crashes in our Lilypond scores that could only be avoided by randomly changing the order of some function calls. Now I sat down and pinned it down quite narrowly: If I use your wonderful \shape function and afterwards override any property of the same grob it causes Lilypond to crash while 'creating systems'. Attached you'll find a file with detailed observations. My impression is that your function somehow messes up with the grob's variable/pointer or whatever, making a copy and not telling Lilypond or such kind of thing. Anyone an idea what could be wrong here? It doesn't make the function unusable (not at all), but it can cause very dubious errors that might be very hard to track (depending on the situation). Best Urs -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. shapeCanCrash.ly Description: ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TupletNumber placement - can you improve this function?
Hi again, > I'm attaching a revised version which works with 2.15.38 which you'll want > to use instead. (It won't work with 2.14.2.) It's somewhat simplified. > One thing that you can do with it is change the distance of the number > from the beam by overriding TupletBracket #'padding (yes, bracket--Lily > positions the numbers according to where the bracket would be, so moving > the invisible bracket pulls the number along with it.) > Turns out I neglected a small correction (half a beam's width), which makes a pretty noticeable difference... (See attached.) -David lsr-646-update05.ly Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Source management tools for lilypond projects
> 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.
It looks similar, but there are big differences! You do not tell them to
leave the file alone, just to not finalize their changes with this file
yet. Every one can continue to work on his part of the things even when
another does wear the master head at that moment. What you are telling by
"locking" is not "do not touch", but "do not update from that" and thus
"do not finalize".
Let me try to explain.
Let's say, A and B are both working on one file. A works on the lyrics, B
works on the polyphony (just let's assume both are in the same file).
In his local copy, A can make as many changes as he wants, and all is fine.
In his local branch, he can even do as many checkins as he wants, still all
is fine.
At the same time, B an do as many changes to *the same* file locally as she
wants. In her local branch, she can do as many checkins as she wants, too.
Now A thinks all is fine with the lyrics. He now tells the group "I will do
an official checkin to the file now". From now on, *the main branch of the
file* is his to work on. He tells the repository program to merge his local
changes to the main stuff. As the main stuff is still the same as when he
created his local branch, all should work well. He does the necessary
consistency checks (like "compiles" and "looks well"), does (if necessary)
a final checkin to the main branch, then tells the group "file is free
again".
Remember, B was working on the same file. Even while A does his release and
locks the file, B gladly continues her work on the polyphony (and thus on
the very file A did lock!). Now, some time later, B finally is content with
the results and could check them in.
First she checks whether someone is holding a lock over the file. As A
already did his final commit, none does, so B can continue. She tells the
group (more on that later) that now she is wearing the master hat for that
file.
Next she tells the repository software to update *her local copy* with the
changes commited to the main trunk in the time between her checkout (the
moment she started to work on the file) and now.
This is the crucial point in which repository programs are such a help: A
and B did simultaneously *work* on the same file, and just the *checkin*
needs to be one after the other!
As A did change the file, the update will change B's copy. Usually, those
changes can be done by the repository software without problems. But if
A's changes and B's changes are too close together (like in the same line),
the software cannot tell which change will have to be kept, and will now
ask B about that.
After these clashes are solved, B has to do all the consistency checks
again. All was well with her changes before she did the update, but maybe
now she has do add some tweaks again.
B goes on making sure the file becomes consistent with policy ("compiles",
"looks well", ...) again.
Then B makes her final checkin, and gives back this file's rubber chicken
for the next one to grab.
How this rubber chicken mechanism is implemented depends on your group,
your requirements (what needs to work after a checkin?), and the software
you use. My approach with the branches would allow you to leave all the
locking and communication to the software. You create your branch at the
moment you start to work on a file, work within that branch until you think
all is well, update this branch from the main trunk to incorporate other's
changes, check integrity again (repeat update/check until there's only very
short time since last update), then commit your changes to the main trunk,
check consistency again to make sure (and correct immediately if needed),
and then forget about the branch afterwards. Only the time between your
committing to the main trunk and the moment you are sure consistency is
still obtained is time where others cannot be asured a newly checked out
version will work fine. This is the only time you might want to 'lock' a
file or even the whole thing.
For all this, no direct communication is necessary, just the discipline to
only make checkins to the main branch only when they do not break
consistency (and rather revert to previous main version and do the
corrections in your work branch than have the main version inconsistent).
Again, how this "main branch" and "work branch" thing is reallized depends
on preferences and the software used. I do not know git (yet), only
subversion (SVN), so I cannot compare.
Hope this helps,
Susan
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Source management tools for lilypond projects
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 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Source management tools for lilypond projects
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. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Source management tools for lilypond projects
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 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Source management tools for lilypond projects
Hi Urs, On Tue, May 22, 2012 at 01:42:14AM +0200, Urs Liska wrote: > Am 22.05.2012 00:53, schrieb Colin Hall: > >On Mon, May 21, 2012 at 11:13:54PM +0200, Urs Liska wrote: > >>In the meantime I had already decided to go this way for the next > >>projects. Our current project that we organize with a shared Dropbox > >>folder starts to become more and more complicated with regards to > >>keeping everything in sync (although it is _far_ better than having > >>independent copies of the folder structure and exchanging everything > >>by email (not to speak about Floppy Disks, which would of course > >>take way too long to be always sent from Germany to Poland and back > >>;-) ) The above paragraph indicated to me that integration of your team's work has been a problem in the past. If that is not the case then build tokens and integration are probably not a concern for you, and my comment was irrelevant. Susan gave a great explanation on "commit often" and the more of that you do, the less you will need to manage integration: > >>>One thing you will have to think about is check-in policy though. I > >>>personally like to check in very often, but that means the checked in > >>>version might not compile, let alone be in a state acceptable to use. > >>>I guess for truely collaborative work you will want to reduce official > >>>check-ins to working versions. This can be combined with my "check in > >>>often" wish by using branches: Work in your personal branch (and check in > >>>there as often as you want) until you are content with the results, and > >>>when an acceptable state of your work has been reached (compiles fine, and > >>>conforms to all the criterions you defined for an official checkin), merge > >>>your changes back to the main branch. And then she mentioned what I know as "integration": > >>>To reduce problems with branch merging (adding changes of the main branch > >>>to the work branch when someone else did a change) If the above step is causing you unmanaged delays, the build token idea can be helpful. Version control does not address this issue. After version control you are still left with the "does my stuff work with your stuff" problem. This is integration. > >The person holding the token has the right to merge in their latest > >work and, in so doing, break the project. They also have the > >responsibility to leave it in a working state before releasing the > >token for the next person. > > > >Leaving it in a working state can mean reverting to the previous > >working version, something that is easy if you have version control in > >place. > > Does that 'token' mean that only one person at a time is allowed to > merge their changes to the repository, while the others have to wait > for their turn? Yes. For the main branch only. As Susan said elsewhere, each person can (and should) have lots of branches of their own and develop freely within them. > But isn't that similar to having a file lock strategy? It is a concept of a lock, but instead of a file lock, it's more like a product lock. If you're interested by these ideas see [1]. Cheers, Colin. [1] http://martinfowler.com/articles/continuousIntegration.html -- Colin Hall ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Source management tools for lilypond projects
Dear Susan, I think this makes sense (although I can't tell if it really is what Colin wanted to express ...). Do I understand correctly that what you describe is one possible strategy to take care of the integrity of the main source tree? 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? 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. This is only acceptable if it is somehow enforced by the system and doesn't rely on the reliability of the people involved. And I feel this may lock up things if someone doesn't give back the token fast enough? Best Urs Am 22.05.2012 10:04, schrieb Susan Dittmar: Dear Urs, I think what Colin meant by "build token" is another strategy to archieve the same as what I described with "checkin/merge to the main branch" and "personal development branches". I think he has in mind a decentralized version control tool, where you first work with your local version, commiting changes to this local version (as I, using subversion/SVN, would have done with a personal branch). Then, when he has the "build token", he first updates his local version with the official changes, debugs his changes until they are in a working state, and then publishes his changes. He makes sure that the published version is up to standard, so no coworker has to debug his stuff. In case he finds his changes make bigger fuss than he thought, he can always give back the "build token" without making any of his changes public (that means he reverts to the previous working thing). Then he does local work again, and when he trusts this time he will be able to make everything work, he again acquires the "build token" to make them public. So, if I understand him correctly, the strategy is the same, just the technology used and their abilities differ. Hope that helps, Susan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Source management tools for lilypond projects
Dear Urs, I think what Colin meant by "build token" is another strategy to archieve the same as what I described with "checkin/merge to the main branch" and "personal development branches". I think he has in mind a decentralized version control tool, where you first work with your local version, commiting changes to this local version (as I, using subversion/SVN, would have done with a personal branch). Then, when he has the "build token", he first updates his local version with the official changes, debugs his changes until they are in a working state, and then publishes his changes. He makes sure that the published version is up to standard, so no coworker has to debug his stuff. In case he finds his changes make bigger fuss than he thought, he can always give back the "build token" without making any of his changes public (that means he reverts to the previous working thing). Then he does local work again, and when he trusts this time he will be able to make everything work, he again acquires the "build token" to make them public. So, if I understand him correctly, the strategy is the same, just the technology used and their abilities differ. Hope that helps, Susan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
