[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: maintaining advanced power-user Scheme functions
From: |
David Kastrup |
Subject: |
Re: maintaining advanced power-user Scheme functions |
Date: |
Mon, 19 Aug 2013 16:28:29 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
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
- Re: maintaining advanced power-user Scheme functions, (continued)
- Re: maintaining advanced power-user Scheme functions, Urs Liska, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Phil Holmes, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Urs Liska, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Phil Holmes, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Urs Liska, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, David Kastrup, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Urs Liska, 2013/08/19
- Re: maintaining advanced power-user Scheme functions,
David Kastrup <=
- Re: maintaining advanced power-user Scheme functions, Janek Warchoł, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Janek Warchoł, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Janek Warchoł, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Phil Holmes, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Janek Warchoł, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Phil Holmes, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Janek Warchoł, 2013/08/19
- Message not available
- Re: maintaining advanced power-user Scheme functions, Werner LEMBERG, 2013/08/19
- Re: maintaining advanced power-user Scheme functions, Janek Warchoł, 2013/08/19