|
From: | Alexander Kobel |
Subject: | Re: Re[surrecting]: Version Control and Public Repository |
Date: | Mon, 30 Sep 2013 15:17:00 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130702 Icedove/17.0.7 |
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.
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.
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.
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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |