I think patch vs branch is not the important question yet.
The real issue is breaking this change down into small, incremental
chunks, and getting as many of them as possible applied to trunk.
Then the non-trivial parts of the patch (i.e., the potentially
destabilizing stuff) can be submitted as a separate patch, or Glenn
can be given a branch. A lot of this patch is trivial stuff like
renames, adding functionally equivalent layers of indirection, etc.
For example, renaming the "berkeley" functions to "bdb" and putting
them behind their own vtable.
If we just put the whole thing on a branch now, then the trivial stuff
will languish there along with the interesting changes. No one will
ever dare to merge the branch over to trunk, because it'll be too big,
thus unreviewable.
Glenn, what we need is for you to resubmit a series of individual
patches (it's okay for them to be serially dependent), where the front
of the series is the trivial stuff, and the end of the series contains
the significant changes.
The trivial ones will be reviewed quickly and applied to trunk if they
look good. Mike Pilato has just committed to this verbally :-), but
he won't be alone. Then you won't have to maintain them anymore, and
we don't have to worry about a huge merge -- everyone wins. (Also, if
the patches get to the point where don't need much tweaking, then
you'll probably just be committing them yourself, even easier.)
After that, we can see what's left. If the remaining change is
complex and experimental, and needs massaging over time, by all means
let's do it on a branch. But maybe it won't be so large, or it will
turn it that it can also be broken down into smaller chunks, or
whatever. We can cross that bridge when we come to it.
I know this is somewhat less convenient for you, but it's the best
course for getting this important change into Subversion. If this
change remains monolithic, it won't matter whether it's in a patch or
on a branch -- it will still be impossible to review.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 22 17:51:31 2002