Re: Managing long patch series

Jim Blandy
2007-10-29T15:03:02Z

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.