On Wed, Apr 20, 2005 at 12:49:28PM -0700, K. Richard Pixley wrote: > Since the hash for f3 and f1 will be identical, we can no longer talk > meaningfully about a linear sequence of revisions. That is, revision id > = SHA1(f3) = SHA1(f1) no longer has a single ancestor nor is there > necessarily even a deterministic path from f3 back to the empty file. > f3 and f1 are different not in content, but only in ancestry. > > Is this history really lost in monotone? Or how is this handled?
This was a problem with versions 0.1-0.14. In 0.15 the history representation was redesigned to fix this problem (and many others). The trick is that the above is true for tree states, but monotone doesn't use tree state ids ("manifest ids") to track history directly. Rather, the "id" that you usually use in monotone is the "revision id"; and a revision is a blob of text that contains, among other things, the id of the parent revision. So it is (barring SHA1 collisions) mathematically impossible for two "different points in time" to have the same id. Furthermore, any given id contains implicitly the entire history of the tree to that point, which can be a handy property. -- Nathaniel -- "...All of this suggests that if we wished to find a modern-day model for British and American speech of the late eighteenth century, we could probably do no better than Yosemite Sam." _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel