On 7/14/10 2:46 AM, "Graham Percival" <gra...@percival-music.ca> wrote:
> On Wed, Jul 14, 2010 at 08:47:17AM +0200, David Kastrup wrote:
>> Graham Percival <gra...@percival-music.ca> writes:
>>
>>> If you have the patch as a single file, then (in vim) it would be
>>> %s/2.13.28/2.13.29/g
>>>
>>> But if you're working on a separate branch (as is right and proper
>>> for a major change), then I'm not certain how to go about it. I'm
>>> looking forward to opinions.
>>
>> I don't see a problem here. Just merge origin/master into your work
>> branch occasionally, then the patch will be relative to the current
>> version.
>
> The problem is the convert-ly rule for the changed syntax -- if he
> wrote the rule for 2.13.25 but doesn't merge until 2.13.29, then
> convert-ly will have an incorrect version. This also applies to
> the version number in input/regression/ files.
>
> I'm not entirely certain why he's changing the version number in
> Documentation/ files, since those should be updated by running
> convert-ly on them (followed by any manual changes that are
> necessary)... but here we're in uncharted and definitely
> disorganized territory.
Because the convert-ly rules are manual rules, so doing convert-ly doesn't
do any good. And I'm trying to keep the changes to only the necessary files
for patch review. For example, I don't run makelsr.py, then upload the
patch (because *all* of the snippets will be changed, not just the ones I
changed for the patch).
So I already have to get the code all patched, do a git commit, do
makelsr.py, make && make doc, make check. Then I do git reset --hard HEAD,
git-cl upload master, and wait for a review.
So for this type of patch, the overhead is quite substantial. I'm thinking
of writing a script that will do the version update automatically, but I
haven't done it yet...
Thanks,
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
