Re: VCS comparison table

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 3786 bytes --]

On Tue, 17 Oct 2006 23:10:34 -0400, Aaron Bentley wrote:
> If B merges A before this, nothing happens, because B is already a
> superset of A.
>
> If B merges afterward, we get this:

Wow. Thanks for elucidating---again I was making some incorrect
assumptions about the system, so your answer was surprising and
appreciated.

So, am I correct in my understanding now that it's impossible for two
users to establish identical code history on both sides through merge?
If the two kept merging back and forth the history would pick up a new
commit each time even though there were no code changes. Right?

That's a startling property. I'm surprised to learn that the
generally-used mechanism for getting new changes doesn't have a mode
where it says "you're already up to date---doing nothing".

I do understand that there's a separate "pull" that does allow for
correct synchronization of a local repository with a remote
repository, and it does have the "up to date---doing nothing"
behavior. But as you already said, it's often avoided specifically
because it destroys locally-created revision numbers.

Another way of describing bzr's "pull" is that it establishes a
master-slave relationship between the remote and local repository,
(his numbers are more important than mine, so I'll throw mine away).
I think Linus already provided a good argument in this thread about
why that kind of asymmetry is bad for software projects and why tools
should not provide it.

So there are some aspects of the bzr design that rob from its ability
to function as a distributed version control system. It really does
bias itself toward centralization, (the so called "star topoloogy" as
opposed to something "fully" distributed).

And by the way, some people seem to have the opinion that there's
something unique about the way the linux kernel is developed that
allows is to benefit from a fully distributed system. The assumption
seems to be that projects with a central tree won't benefit the same
way, and don't really need the full set of features of a distributed
system. That's not true in my experience.

With cairo, for example, we had been using cvs. Obviously, it imposes
a centralized model, but most of the active developers had been using
rsync or other repository synchronization so that we could at least do
offline history browsing. So even with cvs we had as much of a star
topology as possible, (but we didn't have offline commits to our
roaming repositories, nor did we have any sharing between them).

Now, after the switch from cvs to git, we still do have a central
repository that all developers share and push into, (this is distinct
from how linux or the git project itself use git). And git supports
this kind of shared central repository perfectly well.

But a lot of the big advantages the cairo project gets from git come
from our ability to now easily share branches among ourselves without
going through the central repository. We only push fully-cooked
branches to the central tree. But now, with everyone owning their own
publicly-visible repository with all their work in it, we can now
easily share the half-baked ideas we have with all their history. One
person can start an idea, and others can easily pick it up, (without
having to drop down to a mega-patch like we would have done with
cvs). And people actually have the ability to collaborate on turning
an answer into a solution, (in Al Viro's terminology).

So even a project that's very oriented around a single, central tree
can get a lot of benefit from being able to share things arbitrarily
between any two given repositories. And I think that any project will
naturally start doing more of this kind of sharing, (and benefitting
considerably from it), as it adopts tools that support it well.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]