[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: Tom Lord <lord_at_regexps.com>
Date: 2002-08-13 06:57:59 CEST

> You say you're conviced SVN is broken. O.K., that's not far from the
> truth -- we do have several design problems that we've been lugging
> along for quite a while, and we're slowly getting them identified and
> fixed. However, even if we don't manage to fix them before a major
> release, I can't for the life of me understand how that can harm the
> community. What community, specifically, and how would it be
> harmed?

A premature release will, at the very least, raise everybody's
expenses of fixing the problems later. Plenty of other reasons why
its a bad idea, too, but well outside of scope here.

> Subversion (at least 1.0) is targeted mainly at CVS users, and as a CVS
> user myself, I prophesy that particular community can only gain by
> moving to SVN.

As I said, such cliches come across to me as if you had said simply
"talk to the hand".

Do you mean that CVS users are stupid and locked into established
habits? I disagree.

Do you mean that supposed upwards compatibility is often an (all too)
easy sell? I would agree.

   (Off-topic: If you think -- and from your other posts, I surmise you do
   -- that there is only one target community for open-source software, and
   that it's leading light is an idealised perception of Freedom, then I'm
   sorry to say you're wrong. Personally, I use open source software and
   contribute to open source projects first and foremost to make my life
   and other peoples' easier, and I don't care a rusted farthing about
   tearing down evil empires and creating utopias. Both will take care of
   themselves, at their proper time, no matter what I do.)

From what I've seen, large proprietary projects are not substantially
different from open source projects, except that they take place in

   BTW, while you keep saying SVN is flawed, you've never once told us
   _how_ you think it's flawed

Repeatedly I have initiated that conversation from several different
angles. Perhaps these last few messages may begin to clarify.

   You say you wanted to start discussing the patch format to (and I
   paraphrase here) break it to us gently. How would that help? In fact, I
   think it actually hurt, because -- while the intricacies of patch
   formats are interesting in themselves, we already _have_ a patch format
   that's sufficient for our needs, and there are so many more urgent
   things to do that at this point, most of us don't have the time to
   discuss abstract, low-priority issues. (I for one had that post of yours
   marked in my queue for several weeks, but simply didn't find the time to
   post a coherent reply.) It would've been much better if you'd just said,
   "I think SVN is broken _here_ and _here_ because of _that_;" I'm sure a
   very constructive discussion would have ensued.

Perhaps I will be more direct next time.

But there's a problem with just showing up saying X is broken and Y is
broken (and if you read carefully, I still haven't said that). To say
that well and with confidence is horribly time consuming and
difficult: I have to know your code better than you do first.

So I approached you upstream of that point -- after doing some "rough
and ready" analysis of the situation. That analysis left me with
concerns, but also questions. I led with questions and comparisons
that point towards the concerns. An advantage of this approach is
that you might surprise me. You might have answered those questions
in some way I never thought of -- and that caused me to totally
reevaluate my concerns. The questions, invitations, and the
comparisons were the things I was most secure of -- the surest ground
to step off on.


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