Re: maintaining advanced power-user Scheme functions

[David Kastrup]

Urs Liska <address@hidden> writes:

> David Kastrup <address@hidden> schrieb:
>
>>Urs Liska <address@hidden> 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