> From: Greg Hudson [mailto:ghudson@MIT.EDU]
>
> On Tue, 2002-08-06 at 10:17, Alexy Khrabrov wrote:
> > I will predict that you will never see a centralized system evolve
> into
> > a distributed system.
>
> To some extent, this is like someone from Microsoft saying that you
can
> never build a good desktop GUI on top of a Unix-like system, that you
> have to design your whole operating system around your GUI. Microsoft
> has a vested interest in people believing that, and I think most
people
> would say that MacOS X proves they were wrong.
>
> But fundamentally, Larry is right: distributed operation is not one of
> Subversion's design goals, and that is likely to show. Subversion 1.0
> won't be able to copy or merge files between repositories, and you
> certainly won't be able to commit several sets of changes to a local
> repository and propagate them, with history, from there to a central
> repository at a later date. These features might be added at a later
> time, but they might run into fundamental assumptions with resulting
> clumsiness. For instance, the way we handle copy history right now is
> very much tied to a single repository, so if you "svn cp" a file from
> one repository to another, it may turn out that nothing will remember
> where that copy came from, so (unlike a copy within a repository) "svn
> log" won't show the full history of the resulting file.
>
That's only half true, the underlying data model is very well factored
for extension to a more complex multi-repository model at a later date.
This is especially true after cmpilato finishes changing the source
information for a Copy to be Transaction based instead of
RepositoryRevision based. Subversion's data model has only one part of
the data model that determines any order to the system, and that's the
RepositoryRevision information. This should make it very easy to morph
Subversion into a point-in-time/ everything-is-a-branch distributed
system.
Subversion 1.0 isn't a distributed repository system, but it also wasn't
meant to be. That was one of the 1.0 lines in the sand to somewhat
reduce the scope of the problem enough to get traction on getting some
code written.
> The real question, which is yet to be determined, is whether we will
be
> able to handle the 90% of distributed operation which people actually
> want. Some people say that Subversion is already good enough for them
> because you can do local diffs and status operations without talking
to
> any repository at all. So you can do a fair amount of work on an
> airplane, you just can't do intermediate commits.
>
I think the answer is likely to be yes. Larry made an SCCS store into a
distributed system. I don't see why we can't do the same.
Admittedly, there will be corresponding data model changes (mostly table
key extensions) and another repository reload afterwards, but there you
go.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 19:35:59 2002