This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Managing long patch series
- From: Vladimir Prus <ghost at cs dot msu dot su>
- To: gdb-patches at sources dot redhat dot com
- Date: Sat, 27 Oct 2007 10:28:55 +0400
- Subject: Re: Managing long patch series
- References: <m3d4v1d815.fsf@codesourcery.com>
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