cooperate or die

[Tom Lord <lo...@emf.net>]

Let's, suspending our disbelief for the moment, on both these lists,
take the latest and greatest bk flamewar on lkml as indicative of
"where we should (both) be for 1.0".  I know, you in svn-land have a
skillfully managed, very different plan in place.  But, please, for
four more paragraphs, suspend your disbelief.

BK has a per-file, "annotate"-optimizing storage manager PLUS a rich
range of changeset+distribution+fancy-merging features.

`arch' has a really excellent take on
changeset+distribution+fancy-merging features.

`svn' has a really excellent architectural approach to a per-file,
"annotate"-optimizing storage manager.

I'm perfectly happy to stay in the current mutual animosity mode -- I
think arch would _eventually_ "win", but I still believe that there's
a deep potential well there that, if we fall into and suddenly start
cooperating, would lead to a brighter future for all involved.

-t



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: cooperate or die

[Garrett Rooney <ro...@electricjellyfish.net>]

On Sunday, March 16, 2003, at 07:37 PM, Tom Lord wrote:
> We can help you reach those original goals
> "faster, cheaper, better" -- and go beyond them as well.

that's great.

once you have some running code to show us, i'm sure we'll all be quite 
interested in looking at it, but until then, i suspect these 
semi-regular emails trying to convince us to drop what we're doing and 
work on some nebulously defined project to merge svn and arch aren't 
going to do much more than annoy people.

-garrett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: cooperate or die

[Sander Striker <st...@apache.org>]

> From: Tom Lord [mailto:lord@emf.net]
> Sent: Monday, March 17, 2003 1:38 AM

[...]
> We can help you reach those original goals
> "faster, cheaper, better" -- and go beyond them as well.

faster, cheaper, better... Hmmm, we have yet to see the code.
Up until now all attempts of getting us to 'work together' only
have slowed things down...

I'm fine with discussion continueing somewhere other than here,
and you have pointed out that arch-users is the place for that.
Lets keep it there and there only (at least until we hit 1.0,
or when there are actual patches we can discuss).

Thanks,

Sander


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: cooperate or die

[Tom Lord <lo...@emf.net>]

	I don't think we should be targeting the Linux kernel's
	current developer model.

        [....]

         I've written a document about this
         http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot

Is your document a "marketing" tool or a quasi-academic tool?  In
other words, should I read it presuming it is meant to persuade by
reason (quasi-academic)? or should I expect otherwise?  I don't mean
that to be a sarcastic or rhetorical question, though I know it can
easily be construed as such.

The topics addressed in your document are among the kinds of positions
you are invited to come and present and discuss on arch-users, for
your own benefit, as well as for the benefit of others.  Your document
is authored with the presumption that you have some deep insights into
software development and its implications for revision control.  In
spite of the project-specific list name -- such insights are what we
invite you to discuss and compare and contrast with the insights of
others on arch-users.

I have read your document.  It is predicated on (a) your assertion
that there is a deep, objective dichotomy in development models, with
Linux kernel on one side, and projects such as the BSDs, Mozilla, and
Apache on the other and (b) your arguments that the two sides of this
dichotomy imply very different revision control requirements.

I think that the arguments in your document are quite problematic (to
put it mildly) -- but I also wonder if, if you were challenged to find
better arguments, your conclusions would stand -- or whether (what I
think is more likely) you'd realize that svn can be simultaneously
greatly simplified, and made more powerful, by learning lessons from
the arch world which would show you there is not such dichotomy, and
no such variations in requirements.

I must add, also, that the _original_ goals of Subversion 1.0, which
are _still_ goals for Subversion post-1.0, are somewhat contrary to
the position argued in your document.  Specifically, that which you
call "pyramid management" is not really, as you suggest in your
document, equivalent to having a single integrator or distributed
repositories -- rather, it is the least problematic use of
history-sensative merging among branches, which was, as I recall, in
addition to transactions and true renaming, one of the key goals for
svn in the first place.  We can help you reach those original goals
"faster, cheaper, better" -- and go beyond them as well.



-t


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: cooperate or die

[Greg Hudson <gh...@MIT.EDU>]

(Not cc'ing arch-users because, last I checked, it doesn't allow posts
from non-subscribers, and I don't wish to subscribe.)

On Sat, 2003-03-15 at 23:35, Tom Lord wrote:
> Let's, suspending our disbelief for the moment, on both these lists,
> take the latest and greatest bk flamewar on lkml as indicative of
> "where we should (both) be for 1.0".

No.  I don't think we should be targeting the Linux kernel's current
developer model.  It is an albatross among open source projects and it
does not produce good results.  I've written a document about this
(http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot, which isn't as
much of a screed against Bitkeeper as the title suggests), and the
latest flamage allows me to go a little further.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.1/0130.html gives
some reasons why a version control system focused around highly
decentralized development is really hard.  Naturally, Larry has a vested
interest in making Bitkeeper look like irreplaceable voodoo black magic,
but many of his points are valid.  And my answer is: so don't do it. 
You'll never successfully hide all of that complexity from the user, and
contrary to Linus's rabid opinions, the users really should be using
centralized version control.  It yields better results.

Not every Subversion developer agrees with me on all of those points, of
course.  And after 1.0, partial repository replication and/or
cross-repository merging or some other combination of features will
probably make distributed development under svn much easier.  But I
think just about every Subversion developer does agree that Subversion
1.0 isn't about trying to displace Bitkeeper in the Linux kernel.  It's
about providing a compelling alternative for the *BSDs and Mozilla and
Apache and the thousands of Sourceforge projects which use CVS and like
its basic operational model but hate the details and limitations.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: cooperate or die

[Karl Fogel <kf...@newton.ch.collab.net>]

Tom Lord <lo...@emf.net> writes:
> I'm perfectly happy to stay in the current mutual animosity mode -- I
> think arch would _eventually_ "win", but I still believe that there's
> a deep potential well there that, if we fall into and suddenly start
> cooperating, would lead to a brighter future for all involved.

Hmmm.  I was originally planning to not post in this thread.  But
there's a claim here that needs to be refuted, so people who are new
to either mailing list don't get the wrong idea.

Please: there is no "mutual animosity mode" here, except in Tom's head.

Most Subversion users would be perfectly happy if Arch solved all the
problems it set out to solve and took over the world.  I know I would!
I'd switch to it right away, if that were the case. The last time I
tried Arch (quite a while ago), it didn't do that, but that's okay --
things might have changed.  It shouldn't be judged by its early alpha
stages, after all.

The real reason Tom's periodic proposals for some sort of ill-defined
greater cooperation don't get much traction is that they boil down to
a request that Subversion stop in its tracks, reconsider its basic
design decisions, and engage in long discussions of issues that we'd
already hashed out long ago.

There is no way to know in advance whether Tom's proposal is a good
one.  We just have to use our best judgement.  And the Subversion
developers have (apparently) all come to the same judgement: that the
cost of engaging in the proposed stop-and-talk is higher than the
potential benefit, once you multiply that benefit by the non-zero risk
that, for whatever reason, the benefit will never materialize.

That last bit, the risk that the effort will produce no useful results
but will cost both projects time and mental energy, is the bit Tom
always forgets to factor in.  I don't know why he doesn't think it's
important.  I certainly think it is -- it's the sole reason I'm not
tempted by his proposal.

Anyway, my point is: I doubt anyone here feels animosity toward the
Arch project or its developers.  I know I don't, and I've not seen
anything on this list (nor in IRC) to indicate that others do either.
If Tom tells you otherwise, well, his impression does not match
reality, IMHO.  All that's happened here is that some people have made
a decision about how to allocate their own time, and Tom doesn't like
their decision.

I wish Arch luck; and wish also that time were infinite, so there
would be no cost to following other version control projects (and even
participating in them).  Alas, that's not this universe, so we direct
our energies as best we can with limited knowledge.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org