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

Re: SVN is not truly distributed?

From: Mark C. Chu-Carroll <mcc_at_watson.ibm.com>
Date: 2002-08-08 03:16:17 CEST

On Wednesday 07 August 2002 06:12 pm, Zack Weinberg wrote:
> On Wed, Aug 07, 2002 at 04:54:56PM -0500, Jim Blandy wrote:
> > Statements like "you need to design a distributed system to be
> > distributed from day one" are sort of mythological. Who says? Why?
> > It's not really an assertion that one can argue for or against based
> > on the code --- it's more an assertion about the code's soul, or
> > something. So I don't really know how to respond to it. Maybe a
> > shrug is about right.
> >
> > Doesn't BitKeeper itself have some corner cases? Some approximations?
> > Are those cut corners and approximations more or less annoying than
> > those Subversion will inherit from its centralized-server origins? Or
> > is it all just a matter of how much time you put into the details?
> BitKeeper still doesn't support true branches ("lines of development").
> This has been the number one missing feature for three years now. I
> know what the gory details of that problem were in 1999; the situation
> may have changed superficially, but I would bet it still boils down to
> constraints on the implementation coming from the attempt to maintain
> compatibility with SCCS.

This is what kills me about Larry's endless claims that you
can't build a truly distributed SCM system on a non-distributed one.
BitKeeper *is* built using a non-distributed system as its basis, and
it still suffers from some nasty warts as a result; but when it comes
to the distributed part, that doesn't seem to be much of a barrier.

I'm far from an expert on the subversion internals. But I understand
a bit of the basics. And I'm working on an SCM system as well, which
is designed from the ground up to support distribution, despite the fact
that that feature is not implemented in our current system. (We planned
and designed for the capability to support it; we haven't implemented
on that design yet.)

Doing true distribution in an SCM system is *very* hard. But ultimately,
what you need is essentially a globally unique identifier for branches
and versions; an ability to recognize differences between different
repositories using those globally unique branch/version IDs; and
an ability to package up the differences between different repositories
in changesets that allow repositories to reconcile their shared data.

I think that Subversion doesn't yet support globally unique identifiers in
the sense required for Bitkeeper style distribution. But that's *far* from
difficult to add. Subversion currently does, I think, do a style of
changeset in the form of deltas -- which is the basis of the complete
changeset clusters that you need for repository reconciliation. It's
all very posisble to build on Subversion. Not easy mind you - but
there's nothing in the core of Subversion that makes it impossible. To
be honest, it's not even going to be that much harder for Subversion,
which didn't plan support for it in the basic design, than it will be for
Stellation, which planned for it from day one. And I say that as the
leader of the Stellation project, which gives me a clear bias to
give extra credit to the Stellation design!


Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@watson.ibm.com  ------- Personal Email: markcc@bestweb.net
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 8 03:17:22 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.