[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] fs patch was vtable-fi-cation of the fs

From: <cmpilato_at_collab.net>
Date: 2002-11-22 19:34:13 CET

"Glenn A. Thompson" <gthompson@cdr.net> writes:

> 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?
>

> I understand. Which ones do you consider interesting in a general
> sense? Basically, the whole patch revolves around adding indirection.

You patch has some really separable parts (and some parts that
probably didn't need to change at all). I'd like, for example, to see
a patch that strictly covers the renaming of the bdb/*.c functions to
have "svn_fs__bdb" prefixes. I like that change, I should have done
it myself when I did the re-org a while back.

On the other hand, I *don't* like the renaming of 'revision_root' and
'transaction_root' to 'kind_revision_root' and 'kind_transaction_root'
-- just unnecessary mods outright.

> Mike you poor sick puppy:-) Did you get the short straw?

No, I offered to do this since I've been a really vocal opponent
(mostly off-list) of us just giving you a branch. It was an uphill
fight against Ben and Karl (not really), and my offer was a way of
staking a personal connection to this process. I *do* like what I've
seen of your proposal, I *do* think (especially having met you in
person) that competence won't be a concern. But I want our processes
to be beneficial to everyone *and* produce reviewable, excellent code
changes.

> 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.

It's not a problem. All of this *is* our work. Your changes have the
potential to add an amazing feature that we've all wanted for ages, so
we're necessarily torn by assigning time to making sure that
Subversion's near-term goals are met, while still promoting the more
long-term Goodness of the product. It benefits no one if we are so
concerned with today that processes that should be concerrent are
stalled.

   us> $ 'svn lock subversion-design.txt'
   us> $ # go into a hole to work on near-term goals...
   us> $

   you> $ 'svn ci new-hotness.txt'
   you> error: the future seems to be locked by user 'us'.
   you> consider drop-kicking that user.
   you> $

Nah...just isn't a good thing...

---------------------------------------------------------------------
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:36:40 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.