Hi Alexander,
of course I'm interested in this topic ;-) but I have a concert tonight
(anybody in/near Gelsenkirchen?) So I don't know if I can answer in detail
today ...
Best
Urs
Alexander Kobel <n...@a-kobel.de> schrieb:
>Dear all,
>
>long time ago there was this thread about version controlling Lily
>scores, and much more recently Urs' excellent essay and tutorial on the
>
>LilyPond blog [1].
>
>Now, that surely is a great read, but I'm left with one question. Over
>time, I've collected a few scores, made with different LilyPond
>versions, which I want to put into a VCS repo now and clean up a bit.
>At
>some (early) point though, I started to use include files for common
>tweaks and shortcuts.
>So I used, say, my-tweaks-0.1.ly for scoreA, and an extended version
>my-tweaks-0.2.ly later for scoreB. Now I recognize that it feels wrong
>to maintain my-tweaks-* in different files, because it really is a
>development from 0.1; also, it means copy-pasting to a new file
>whenever
>a nice add-on should be available for new scores. "Where's my most
>recent house style?"
>On the other hand, some tweaks introduced in newer versions of the
>include do not work well together with local tweaks of scoreA; hence, I
>
>want to at least refer to which version of my-tweaks-?.ly I used there
>last time I touched the piece. (E.g., I have scores which predate Joe's
>
>tremendous improvements to vertical spacing; it's obvious that I have
>to
>rewrite all spacing code if I convert them to today's Lily, but I need
>the old state of tweaks for everything else.)
>
>I'm pretty sure that's a common problem for repos containing several
>separate projects, unlike source code for a single library or
>application which needs to be updated entirely in one shot when
>dependencies change. So, most probably there's a `proper` way to deal
>with the problem. But, which? Any suggestions?
>
>The only possibility I see to keep the different versions (in git)
>somewhat cleanly separated is to use a house-style branch for the
>includes, and use one branch per project (a.k.a. score). If necessary,
>merge the recent modifications from house-style to project. This sounds
>
>clean, but also like overkill - after all, I usually write 2-4
>pages-scores (max was around 20 pages, I think), not operas.
>On the other hand, I preferably don't want to check every time I modify
>
>an include whether the change has negative impact on any of my score,
>but I also don't want to be stuck with some broken old project for a
>little modification. (Like, extract choir parts from the piano
>reduction--which typically happens ~1 hour before the rehearsal...)
>
>
>Thanks in advance,
>Alexander
>
>
>[1]
>http://lilypondblog.org/2013/09/write-lilypond-code-for-version-control/
>
>_______________________________________________
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user
--
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
