On Tue, 17 Oct 2006 21:00:51 -0400, Aaron Bentley 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. 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? So in that situation the numbers will not help A and B determine that they have identical history or even identical working trees. So what good are the numbers? 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. -Carl
| Justin C. Sherrill | Re: pkgsrc bulk build and tiff |
| Linus Torvalds | Linux 2.6.27-rc5 |
| Ingo Molnar | [crash, bisected] Kernel BUG at ffffffff8079afb1 (__netif_schedule()) |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Evgeniy Polyakov | Re: tbench wrt. loopback TSO |
