Graham Percival <gra...@percival-music.ca> writes: > On Tue, Jul 13, 2010 at 05:30:38PM -0600, Carl Sorensen wrote: >> Because it changes the syntax, I need to change documentation text, >> documentation examples in english, french, spanish, and german (plus >> potentially in hungarian and japanese), documentation snippets, regression >> tests, web examples, and convert-ly. Every one of these files needs a >> version. (And I haven't yet mentioned changes.tely). > > Hmm, I hadn't thought of that. > >> How the mao am I supposed to get a patch reviewed? I prepared the patch for >> 2.13.27, then updated it for 2.13.28, and now we're at 2.13.29. The review >> cycle is *longer* than the release cycle! I suppose there's some way to use >> xargs to fund the files changed in the patch and automatically (using sed) >> change every occurrence of 2.13.28 to 2.13.29, but I don't have the bash >> script-fu to do this. > > 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. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
