2013/8/19 David Kastrup <d...@gnu.org>: > Urs Liska <u...@openlilylib.org> writes: > >> Version control _can_ be useful for a collection like the LSR. Think >> of providing snippets for more than one LilyPond version. If I'm using >> 2.16 I will download a different snippet than for 2.17.24 ... > > But that's not what version control is for. Version control does not > fundamentally work with a series of codependent equally active HEADs, > but rather has one principal HEAD of development, and historic > references (quite likely containing _inferior_ code, and inferior for > reasons that are often only marginally related to the LilyPond version).
That's true. However, i think that it ultimately /makes sense/ with LSR. Look at it this way: 1) let's say Lilypond 2.18 is released and all snippets are upgraded to work with it. This is the master branch (what's visible by default via the web interface), and it gets a tag "state as of 2.18 release". 2) LilyPond is continues to be developed in 2.19 series. People occasionally write new snippets that require 2.19 (or update existing ones from 2.18 to 2.19) - commits doing this do to a separate "develop" branch, and are not visible by default via the web interface, but advanced users can easily access them. This is the "improvement" part, as one upgrades a snippet to 2.19 precisely because it will work better. 3) at the same time, new snippets that work with the 2.18 release are added (and some snippets are improved), and this goes to the master branch. 4) when lilypond 2.20 is released, master and develop branches are merged. 5) the circle starts again. Janek _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
