Urs Liska <u...@openlilylib.org> writes: > David Kastrup <d...@gnu.org> schrieb: > >>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). > > I think developing input files to keep up with LilyPond versions _is_ > natural to Git. Snippet versions which are compatible to a certain > older version of LilyPond are legitimate 'historic references'. > > Accessing them in parallel isn't natural, that's right. But it could > be made manageable. On Github for example you can access files on > different branches through different url paths.
Ok, so we have a branch for version 2.17.2, a branch for 2.17.3, a branch for 2.17.4, a branch for 2.17.5 ... Now I update a snippet for the 2.17.4 branch. How will the update percolate to the branches 2.17.5...2.17.25? Basically, an automatic procedure would try to run convert-ly repeatedly and check everything in that has not been superseded by a manual checkin: after all, if I have replaced the snippet in 2.17.20, the replacement should most likely stick around. Or not: might be worth to flag an "update conflict" and wait for human resolution like a rebase does. > I don't want to say that it's dead easy, though ... Yup. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
