Managing long patch series

[Vladimir Prus]

Jim Blandy wrote:

> 
> Ulrich, I'm curious what techniques you use to manage these long
> strings of patches.  Specifically, I was wondering:
> 
> - I'm usually working from a fully-patched tree, and then breaking it
>   up into digestible pieces for submission.  If you are working this
>   way as well, do you have a nice way to ensure the decomposed patch
>   series remains equivalent to your fully-patched tree?
> 
> - Often I find I need to revise an earlier patch in the series, but
>   that chance may affect later patches.  Do you have a nice way to
>   handle this?
> 
> Or is it all just "blood, sweat, and tears"?  In the software world,
> that approach usually results in "mistakes", but you and your fellow
> IBM GDB hackers seem to do well.
> 
> I've tried using quilt, but if one doesn't keep very careful track of
> what's going on things can get very tangled.  The Emacs mode helped
> somewhat, but had other flaws, so I set it aside.
> 
> I've been tempted to try using Mercurial for this.

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.

-  Volodya