Hey:
Karl Fogel wrote:
>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.
>
>
OK. I can take a wack at it. But the next couple weeks I really have
to focus on my other work.
So I may just keep updating every night. I have been doing it for
weeks. In other words just keep it working locally.
Then when I get my time back, I'd do as you suggest. Is that OK?
>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.
>
I understand. Which ones do you consider interesting in a general sense?
Basically, the whole patch revolves around adding indirection.
>
>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.
>
>
OK. I may need some help identifying what is an appropriate first patch.
Would the trail vtable combined with the (baseline_db_access_funcs_t now
called svn_fs__bl_db_access_funcs_t) be too huge? It would at least
limit all changes to libsvn_fs and below. Actually, no it won't. The
test stuff would still have to change some. Once I rename the bdb
functions, it would be nice to go ahead and add the indirection as I
will have to change those lines anyway. Certainly the api vtable can
come later That one is a bit scary hun? But I really do need it long
term. Some of the structures I moved into fs-base-impl.h I may be able
to move in a second round. Sorry guys. I guess I'm a little monolithic
in my thinking:-) Let me simmer over the weekend.
>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.)
>
>
Mike you poor sick puppy:-) Did you get the short straw?
>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.
>
>
>
It's alright Karl. I kinda expected this. After all, I've already
pulled some changes out. As I tried to explain to Ben and Mike at
dinner. My struggle was how to show where I'm headed on this stuff. My
initial web pages did a poor job. So, I just rolled and rolled and
rolled thinking the code would do it. I'm much better at verbal
communication than written.
Maybe as part of a litmus test I could submit a patch to config.c The
changes are only used by my SQL code ATM, but only two files change!
I'm sorry if I diverted you guys from other work. Assuming I can meet
svn standards, I will help out on the milestones down the road to help
make up for my coming to the party so late.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 22 19:15:54 2002