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:
pgpfwzVXy15kX.pgp
Description: PGP signature