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

[Franciszek Boehlke]

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

On 09/30/2013 10:23 AM, Urs Liska wrote:

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.

True. And merging will become problematic at some point, too, even if you always try to stay up-to-date.

Merging? Why can it become problematic, if you would never work on one file in different branches? You should never get any conflict, for merge just type `git merge whatever-branch -m 'piece of cake'` and you are done.

Actually, this drawback is present only, if you want to work on scores using older versions of tweaks, without updating them. In other case, you don't need to keep branches for them. And, as i wrote before, don't hesitate before creating new branches, their are cheap, and merging is no problem (unless you have real conflicts).

 

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.

I guess that's the somewhat simplified version of Curt's suggestion to use git submodules (simplified w.r.t. the learning curve, not necessarily the overall effort in the long run).

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. [...]

Agreed.

Agreed. So, if you want to keep library as standalone project, it would be preferrable to keep it in it's own repo.

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.

The drawback is, that you have to keep track of versions manually, instead of having it done for you by git.
 

I guess I'll stick to a Makefile entry, for simplicity...

Maybe I should try to guard potentially backwards-incompatible changes and only define them if some variable is set; in this case, it probably means that I can live with only the most recent library checked out. Of course, it'd also be a workaround for being lazy about version control, rather than a real solution, but it's K(ing)ISS.

If you can afford it without big complications, it is probably best solution.

 

Thanks to all for your input; I'm somewhat tempted to ignore all your proposed proper solutions, but at least now
- I have an idea of what The Real Thing is,
- I am reasonably confident that I didn't miss an obvious and easy solution, and
- if I shoot me in my foot, I already know that it was my free choice and I mustn't complain...

To cite the Gnus manual:
"You know that Gnus gives you all the opportunity you'd ever want for shooting yourself in the foot. Some people call it flexibility. Gnus is also customizable to a great extent, which means that the user has a say on how Gnus behaves. Other newsreaders might unconditionally shoot you in your foot, but with Gnus, you have a choice!"


Best,
Alexander

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user

Best,

Franek