[Developers] Re: patch: CactusEinstein/IDAxiBrillBH cleanup

[Jonathan Thornburg]

Hi, Tom,

> In general, small, specific patches will get quicker attention, and thus 
> lower latency, than big patches which do lots of different things.  If you'd 
> sent a note out to developers that you were doing this, and followed with a 
> sequence of patches as you did things, it would have been easier.

Well, actually I _did_ send a note out to developers about an early
(partial) version of this set of changes.
   http://www.cactuscode.org/pipermail/developers/2005-April/000822.html

It wasn't a full-fledged "patch" then, because I didn't yet think I
had a working version of IDAxiBrillBH.  (In hindsight I _did_ have a
working version, the bugs I was seeing lay elsewhere.  But I didn't
know that then...)

The only reply I saw was from Erik,
   http://www.cactuscode.org/pipermail/developers/2005-April/000823.html
suggesting that I keep backwards compatability.  Inspired by his
suggestion, I did so in my later changes.



There is a larger problem, however:

> although as you note at the bottom it
> would be good if you could split the commits into smaller units, each
> addressing an individual thing, e.g.
> 
>      relabeling latex
>      adding comments to param.ccl
>      adding the interpolator parameters
>      adding new output (I agree that it should really be a GF so we can
>                         use standard Cactus IO methods)
>      add debugging stuff
>      adding new stuff to the documentation
>      etc

Let's look for a moment at the process by which I could do this:

1. start with old version from CVS
2. discover and fix problem #1
3. create 'version 2 - version 1' patch, write description,
    and send the whole thing to the appropriate mailing list
4. go on to discover and fix problem #2
5. oops, how do I create a 'version 4 - version 2' patch?
    I don't have a copy of version #2 any more, and it's not in CVS
    (because the 'version 2 - version 1' patch hasn't been approved yet)
    Ok, so I need to check out a clean copy of the old version from CVS,
    and roll it forward with the 'version 2 - version 1' patch.

As you can see, this gets rapidly (maybe even quadratically) messier
as one accumulates more and more changes.  By the time you get the
dozen-plus changes incorporated in my current IDAxiBrillBH patch,
it's just not practical.

I admit that, had I known 6 weeks ago that I was going to make such
extensive changes, I might have saved lots of intermediate versions.
But I didn't.

 	[In fact, it's even worse than that.
 	Even if I had saved a 'version 2', a "version 4 - version 2'
 	patch wouldn't apply cleanly after the 'version 2 - version 1'
 	patch had been committed... because the $Header:$ lines
 	in all the files will be different.]





So, to repeat the closing question from my patch message:

> Apart from "switch to darcs", is there an elegant solution to this
> problem?

Should I create a private CVS branch for each code change that I
think I might eventually want to submit as a formal patch?

ciao,

-- 
-- Jonathan Thornburg <jthorn at aei.mpg.de>
    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
    "Washing one's hands of the conflict between the powerful and the
     powerless means to side with the powerful, not to be neutral."
                                       -- quote by Freire / poster by Oxfam