This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Managing long patch series


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'm handling this manually.  Usually, I have two trees: one vanilla
check-out at a particular stage, and one "work tree" that started
out as a copy of the vanilla tree with my changes added.

To re-base a patch set to mainline changes, or to some change in an
earlier patch in the series, I'll typically go back to making the
work tree a fresh copy of the vanilla tree, apply the first patch,
resolve any conflicts, re-diff against the vanilla tree to get a
new 'clean' version of the patch, apply the clean patch to the
vanilla tree, then apply the second patch to the work tree and so on.
(After the refresh is complete, I revert the whole series from the
"vanilla" tree again, and verify that "cvs diff" is back to empty.)

I try to break changes out into separate patches earlier rather than
later if possible, but of course on occasion I still break up a big
changeset into multiple smaller ones.  To make sure the broken-out
patches still combine back into the original on, I'd typically
compare the work tree after applying the small patch series against
the vanilla tree with the old big patch applied.

> 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 understand that quilt employs a method that is similar to the
manual approach I'm currently using, so if I were to use some tool,
quilt would probably be it.  (However, I'm a vi person, so I have no
opinion either way on the Emacs quilt mode ...)

> I've been tempted to try using Mercurial for this.

I've never used that, sorry.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]