Re: VCS comparison table

From: Aaron Bentley <aaron.bentley@utoronto.ca>
Date: Oct 18, 2006, 03:10 UTC
Message-ID: <45359B2A.1070102@utoronto.ca>
In-Reply-To: <871wp6e7o9.wl%cworth@cworth.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carl Worth wrote:

Show 11 quoted lines

> Aaron, thanks for carrying this thread along and helping to bridge
> some communication gaps. For example, when I saw your original two two
> diagrams I was totally mystified how you were claiming that appending
> a couple of nodes and edges to a DAG could change the "order" of the
> DAG.
> 
> I think I understand what you're describing with the leftmost-parent
> ordering now. But it's definitely an ordering that I would describe as
> local-only. That is, the ordering has meaning only with respect to a
> particular linearization of the DAG and that linearization is
> different from one repository to the next.

Well, the linarization for any particular head is well-defined, but since different branches have different heads...

Show 6 quoted lines

> If in practice, nobody does the mirroring "pull" operation then how
> are the numbers useful? For example, given your examples above, if
> I'm understanding the concepts and terminology correctly, then if A
> and B both "merge" from each other (and don't "pull") then they will
> each end up with identical DAGs for the revision history but totally
> distinct numbers. Correct?

The DAGs will be different.  If A merges B, we get:

a
|
b
|\
c d
|\|
| e
|/
f

If B merges A before this, nothing happens, because B is already a superset of A.

If B merges afterward, we get this:
a
|
b
|\
d c
|/|
e |
|\|
| f
|/
g

> So in that situation the numbers will not help A and B determine that
> they have identical history or even identical working trees.

They don't really have identical history.

> So what good are the numbers?

They are good for naming mainline revisions that introduced particular changes.

> I can see that the numbers would have applicability with reference to
> a single repository, (or equivalently a mirror of that repository),
> but no utility as soon as there is any distributed development
> happening.

Well, there's distributed, and then there's *DISTRIBUTED*. We don't quasi-randomly merge each others' branches. We have a star topology around bzr.dev. So when we refer to revnos, they're usually in bzr.dev.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNZsp0F+nu1YWqI0RAkmWAJ9PkrkubIHVgAn5Wbdkg9IBAHCviACdFx2x 6ClmK4GmC1pRuRQACcSijNM= =SM1Y -----END PGP SIGNATURE-----