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

[Urs Liska]

Am 28.09.2013 00:10, schrieb Franciszek Boehlke:
> 2013/9/27 Alexander Kobel <address@hidden>
>
> 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.
There is another, more severe drawback to this approach.
Yes, you can always get back to the state when you last touched this 
score. The library will automatically be in the right state and you can 
compile the score.
But as soon as you want to modify the score again you're stuck at some 
place in your history. You'd have to create a new branch solely for that 
score.


I don't have a ready solution that I have already tested, but I think 
the following approach should work, is sufficiently 'clean' and not too 
complicated:
You should have (at least) two Git repositories, one for the library and 
one for the projects.
This is natural because a shared library _is_ conceptually separated 
from the project, that's why it _is_ a library and not simply a project 
file.

So if you have one library with all your personal bits and pieces, store 
them in one Git repository. If you have different libraries with 
different purposes, use one repo for each.
Store your project(s) in one or more repository/ies, depending on their 
complexitly. If your projects are short individual scores they can go 
into one common 'projects' repository (I have a 'notation' repo for such 
diverse stuff). If you have complex projects with lots of files it's 
probably better to have individual repos).

For the library repo do the following: Create a history that reflects 
the development of the library:
(simplified)
- add the oldest version of the library and commit
- overwrite with the next version and commit
- etc.
For better overview use tags

For the projects repo you don't have to do any versioning precautions, 
just add your scores (I suggest to commit each addition individually, 
but you can of course also put everything in and do an 'initial commit' 
with all scores).

Now you can work on the scores as you like and for compiling them 
checkout the right tag in the library repository. (Be sure to always 
have the working tree of the library repo clean.)
I think this should work without problems.
Of course you should add a comment specifying the library version to be 
used (and maybe also LilyPond version).
I could imagine that one could even have a Scheme function that does the 
library checkout for you, but that's clearly over my head.

HTH
Urs