Aaron Bentley wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Carl Worth wrote:
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...
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).
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.
As explained above, they would be identical in git. The fact that you
register a fast-forward as a merge makes them not so, but this is
something most gitizens are against, as it can quickly clutter up the DAG.
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.
So in essence, the revnos work wonderfully so long as there is a central
server to make them immutable?
Doesn't this mean that one of your key features doesn't actually work in
a completely distributed setup (i.e., each dev has his own repo, there
is no mother-ship, everyone pulls from each other)?
I can see the six-line hook that lays the groundwork for this in git
before me right now. I'll happily refuse to write it down anywhere. I
get the feeling that sha's are easier to handle in the long run, while
revno's might be good to use in development work. In git, we have
<branch/tag/"committish">~<number> syntax for this.
In my experience, finding the revision sha of an old bug is what takes
time. Copy-paste is just as fast with 20 bytes as with 4 bytes. Honestly
now, do you actually remember the revno for a bug that you stopped
working on three weeks ago, or do you have to go look it up? If someone
wants to notify you about the revision a bug was introduced, do they not
communicate the revno to you by email/irc/somesuch?
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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