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

Re: [lord@regexps.com: business models and revision control]

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-08-13 05:43:45 CEST

On Mon, 2002-08-12 at 22:20, Tom Lord wrote:
> 1) too complicated
> 2) depends on too many other pieces
> 3) too centralized
> 4) peculiar (at best) user interface
> 5) questionable storage manager semantics
> 6) out of control (judging by bug reports on the dev list)

Some of your issues fit in the category of "subjective and somewhat
arbitrary," and were decided, for better or for worse, in the early days
of the project. Should a CVS replacement focus on distributed
operation? You, Larry McVoy, and a lot of my friends would say yes. If
some of those people had been around and spoken up early on, Subversion
might have a very different design. It might be frustrating to
acknowledge that Subversion will have to retrofit distributed operation
if it ever gets it at all, but asking the project to throw away its
architecture and start over is too much. You can go your own way, of
course, but only if you have the resources to make that fly.

Some of your issues are solvable. I hope to contribute towards freeing
Subversion from its dependencies on Berkeley DB and Apache/Neon. (No
guarantees, of course.) But I won't do that by asking the team to scrap
its existing storage manager and repository access mechanisms, or even
by asking the developers to consider designs of new modules before 1.0
is substantially ready. That wouldn't be constructive.

Some of your issues are based on a skewed perspective of the product.
Before I actually picked up a copy of svn and tried it out, I was
worried that it rested on a pretty shaky foundation too. But aside from
a bunch of surface-level bugs, it feels pretty solid if you actually use
it.

Some of your issues are too vague to respond to.

It is important not to let the perfect become the enemy of the good,
even when you can agree on what perfect is. Doubly so when you can't.
As unpleasant as it is to be trapped by past mistakes, you can't make
any progress by being afraid of your own shadow during design.

> the lack of uptake on these issues from the svn developers
[...]
> "talk to the hand"

You haven't gotten much response from people here for several reasons
(all my personal opinion):

  * Most people are mystified by your comments. Your arguments retreat
    very quickly into the abstract, leaving most people confused about
    what you were trying to say. When you do stay in the specific, you
    often do so in a fashion too wordy to be waded through by most
    people (as with your several-hundred-line proof that tree
    reorganization deltas don't need to include information about files
    which weren't added or removed or moved).

  * Many of your messages don't appear well thought-out, as witnessed by
    your tendency to reply to your own words. A note to a technical
    mailing list should receive at least as much care as an equivalent
    amount of code.

  * You haven't built up credibility by making positive contributions
    before asking people to accept your judgment about sweeping
    architectural matters--often without justification.

  * You've asked people to reconsider fundamental decisions from long in
    the past, without recognizing that a tremendous burden of proof
    falls on the party asking for a reversal of such a decision.

  * Very recently, you've been raising a number of off-topic concerns on
    the list, and even making appeals for funds. This list has a
    charter, and the less you stick to it, the less people will listen.

You might have justifications for some of this behavior, but that
doesn't matter; it has the same effect whether it's justified or not.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 05:44:17 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.