lilypond-user
[Top][All Lists]
Advanced

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

Re: Re[surrecting]: Version Control and Public Repository


From: Urs Liska
Subject: Re: Re[surrecting]: Version Control and Public Repository
Date: Fri, 27 Sep 2013 12:55:10 +0200
User-agent: K-9 Mail for Android

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 <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
reply via email to

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