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