Re: Managing long patch series

[Jim Blandy <jimb at codesourcery dot com>]

Vladimir Prus <ghost at cs.msu.su> writes:
> I was using SVK for that. I have //patches/patch1/ ... //patches/patchN
> then if I modify patchX I use svk smerge to update all later patches.
> When mainline changes, I smerge from mainline mirrors to patch1 and then
> smerge between (1->2, 2->3,  N-1->N).
> The only gotcha I found is that you should always apply mainline changes
> to the first patch and then propagate it via the chain. If you try
> to apply mainline changes to a patch in the middle, SVK mergeinfo
> representation may fall appart, and given you random conflicts in
> fugure.

Okay, that's interesting.  I think I can see how this would be done in
Mercurial, too.  I'd done something equivalent to merging into the
middle of the chain with the tracepoint patches; I guess I'll learn
soon enough whether its metadata representation disintegrates. :)

Tom Tromey referred me to Mercurial Queues, which looks really good:

          http://hgbook.red-bean.com/hgbookch12.html

The reason I'm so fond of Mercurial is partially that it's quite fast.
You can jump from one place to another easily.  I have a tree
which is simultaneously a CVS checkout and a Mercurial repository,
that I use as a gateway between the two; I say, essentially:

   cvs update
   hg addremove
   hg commit -m 'from public CVS'

from time to time, and then I can pull those changesets into whatever
other working copies I have.  My .hgignore file tells Mercurial to
ignore the 'CVS' subdirectories, and I just ignore the '?' markers
from CVS for '.hg' and '.hgignore'.  It has all worked nicely so far.

It sounds like you're doing something similar with SVK --- unless
you're pushing/pulling from CodeSourcery's internal SVK repository.