On Sat, Oct 21, 2006 at 02:04:56PM -0700, Linus Torvalds wrote:
> On Sat, 21 Oct 2006, Erik B?gfors wrote:
> > bzr is a fully decentralized VCS. I've read this thread for quite some
> > time now and I really cannot understand why people come to this
> > conclusion.
>
> Even the bzr people agree, so what's not to understand?
>
> The revision numbers are totally unstable in a distributed environment
> _unless_ you use a certain work-flow. And that work-flow is definitely not
> "distributed" it's much closer to "disconnected centralized".
>
> Now, you could be truly distributed: BK used the same revision numbering
> thing, but was distributed. But BK didn't even try to claim that their
> revision numbers were "simple" and that fast-forwarding is sometimes the
> wrong thing to do.
>
> So BK always fast-forwarded, and the revision numbers were just randomly
> changing numbers. They weren't stable, they weren't simple, and nobody
> claimed they were.
>
> So bzr can bite the bullet and say: "revision numbers are changing and
> meaningless, and we should just fast-forward on merges", or you should
> just admit that bzr is really more about "disconnected operation" than
> truly distributed.
>
> You can't have your cake and eat it too. Truly distributed _cannot_ be
> done with a stable dotted numbering scheme (unless the "dotted numbering
> scheme" is just a way to show a hash like git does - so the numbering has
> no _sequential_ meaning).
>
> Btw, this isn't just an "opinion". This is a _fact_. It's something they
> teach in any good introductory course to distributed algorithms. Usually
> it's talked about in the context of "global clock".
>
> Anybody who thinks that there exists a globally ticking clock in the
> system (and stably increasing dotted numbers are just one such thing) is
> talking about some fantasy-world that doesn't exist, or a world that has
> nothing to do with "distributed".
>
> Linus
Actually bzr used to have slightly different numbering scheme not long
ago. There was a revision-history in each branch listing the revisions
in order in which they were commited or merged in. Some time ago it was
changed to numbering along the leftmost parent, which was, IIRC, deemed
simpler and a little more logical. But in the light of these arguments,
maybe the former system was better -- it was more dependent on the
actual location, but on the other hand it allowed (or could allow --
IIRC there was some problem with it) to fast-forward merge while
_locally_ keeping the meaning of old revision numbers. In fact, the
revision-history used to be almost exactly the same as git reflog,
except it only stored the revids, not the times.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@xxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html