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

[Franciszek Boehlke]

2013/9/27 Alexander Kobel <address@hidden>

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

I have not real experiance in using git that way, but can imagine a bit how does it work. I think there are two main ways you can go, and possibly using submodules is the third.

One way (which i would recommend) is working on one branch, updating tweaks and not bothering with breaking compatibility at all. It will make some scores unusable with the newest version of tweaks, but it is not really a big problem: you can always ask git for the latest commit, which changed score A (), and checkout this particular commit before compiling this score. Drawback: if you want to update score to some intermediate version of tweaks, you have to make it in new branch. However, if you generally update always to the newest version, it is not a problem at all.

Second way is to keep every score, or some bunches of scores, in separate branch, and tweaks also in separate branch. Then, in every score-branch, you keep working version of tweaks, and can merge newer tweaks, fixing conflicts.  This is, in a way, very clean solution, but it introduces a lot of unnecessary fuss and lot of branch switching, which is generally inconvenient: your files are hidden in repository, and you have to checkout branches to access them. What's even more inconvenient, is working on tweaks - if you fix them while beeing on a score-branch, you have to merge this change back to tweak-branch. It is just one line, but forgetting it may then lead to stupid conflicts. So, I think it is clearly an overkill, as long as you are not going to developp your scores in parallel, updating them to subsequent tweaks versions (which is not case, i suppose).

Possibly there are some other ways (submodules? I doubt they are really a solution, it is probably other way to overkill), possibly mixing somehow this two attemps, but for what you described, i will try the first one: just putting everything together, and checkouting proper commits for compiling old scores. Btw, you can still develop scores in their own branches, if you like - in git it is never a problem ;)

Generally, it is important property of git: branches cost you _nothing_, and merging them is easy. So, if you ever like to have new branch for anything, just create it :)

I hope i didn't make things too complicated.

What you need for first approach:

git log <filename>

prints commits (starting with latest), which touched metioned file; each commit is identified by so-called commitish (sha1 sum), sth like 7b7e37e8ab4fa9662ef6d3c0a8ce6f516731e831.
git checkout <commitish>

reverts all files to state saved in commit identified by <commitish>. Important: after this command you are no more on any branch, and if you make a commit, it may get lost. You will get proper warnong from git.
git checkout <branch-name>
reverts all files to state saved in last commit in branch, and set branch as current, so every subsequent commit will go into it.

If you experience any problems, I'll be glad to help :)

Cheers,

Franek