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: Curt
Subject: Re: Re[surrecting]: Version Control and Public Repository
Date: Fri, 27 Sep 2013 13:53:48 -0700

This is a common problem in software engineering.  In my day job as a java 
developer we use something called archiva which collects multiple versions of 
the libraries we depend on.  So if projectA (like your score) depends on 
version 1.1 of a library (like your tweaks), while another project depends on a 
different version, then they'll both be available, and the appropriate version 
would just be pulled in.  That tech is specific to java and maven though I 
think.

For a git-only approach, the *classic* way of handling this - and I haven't yet 
tried this myself, so I might not be describing this quite right - is to use 
submodules.  So you would have a separate repository for your tweaks, with tags 
for the different versions you care about.  Then you could pull the submodule 
into your project(s), each pegged at the appropriate version number.  However, 
I think this would require each of your score projects to be in a separate 
repository.

If you keep all your scores in the same repository, and each score project 
depends on a different version of your tweaks file, then I can't immediately 
see a way to do what you want - you'd probably be stuck with having copies of 
your tweaks library, with different version numbers in the file names.

Curt

On Sep 27, 2013, at 2:11 AM, Alexander Kobel <address@hidden> wrote:

> 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




reply via email to

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