Re: VCS comparison table

2006/10/18, Andreas Ericsson [off-list ref]:

Aaron Bentley wrote:

quoted

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

Carl Worth wrote:

quoted

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...

quoted

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

Seems like an awful lot of merge commits. In git, I think these trees
would be identical (actually both to bazaar and to each other), with the
exception that the 'g' commit wouldn't exist, since git does
fast-forward and relies on dependency-chain only to present the graph
instead of mucking around with info in external files (recording of
fetches).

Ok. This I don't get. Let me recaptulize:

Branch A
a
|
b
|
c

Branch B
a
|
b
| \
d c
| /
e

In branch A, do merge branch B (git pull B) you get as result branch B, because
A fastforwards to B and you don't get a merge commit f

In branch B, do merge branch A (git pull A), the result would be
branch B, because
we are already uptodate.

You _never_ have a commit f or g.

-Peter