Am 28.09.2013 00:10, schrieb Franciszek Boehlke:
2013/9/27 Alexander Kobel <n...@a-kobel.de>
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
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
