On 8/26/2009 4:02, Taylor R Campbell wrote:
In any case, irrespective of precisely how this cache is constructed, will any such mechanism ever be included in Darcs to reduce the frustration of waiting for `darcs changes<pathname>'?
I think that one such cache or another will eventually make its way into darcs. The most recent work on caching has been to speed up hashed pristine reading (particularly for ``darcs whatsnew``) and there are still a few commands that aren't using that index that could be for speed benefits. I believe, the file cache is then probably "next" on most developers mind on the caches to implement list.
I am emphatically not immersed in Darcs lore, but it has always been my intuitive impression that if two repositories have no patches to pull from or push to one another, then they have identical contents. In #darcs, Simon Michael (sm) answered `yes' when I asked whether this is true. I didn't say exactly what I meant by `identical contents', because, as I said, this is only an intuitive impression. Obviously I don't mean that *everything* is the same (e.g., the preferences), but at least the state of the pristine tree and the collection of patches. If this is so, then despite what O'Sullivan says, it seems unnecessary to be immersed in Darcs lore in order to tell whether two repositories have the same state, if one is reachable from the other: if `darcs pull' followed by `darcs push' report no patches to transmit in either direction, then the repositories have identical contents. However, this is a heavy-handed test, so I wonder: Can the state of the repository be summarized in a concise string such as a hash, or dumped consistently, say, to a stream of bytes that can be piped to `openssl dgst', so that if two repositories have identical contents, then they will show the same summary (hash)? What if I said `iff' instead of `if'?
The pull/push test seems reasonable. I'm also a fan of "when in doubt, get a fresh copy of that branch".
There is a lot of complaints that there isn't anything so simple as a hash to encompass "securely" a given reproducible, repository state. Issue 992 in particular has a lot a lot of discussion on that topic.
Darcs can encode the current "exact" state of a repository into a context file with ``darcs changes --context``. These can be compared to see if repositories contain the same patches. These can also be used to reproduce a repository state.
In the trivial cases you could hash context files and check those. Because of commutation two repositories might have patches in different orders, so the hashes might be different but the set of patches might be the same. Small contexts you could double-check by hand. Medium ones you can use a diff tool to help you check it. Larger ones you could do a ``darcs get --context`` and the push/pull test.
The fact that there isn't a quick "are these two context files equal" tool in darcs or the darcs ecosystem is probably an oversight, or maybe "it isn't needed as often as people from other systems think it might be". (I'm thinking a fast, very-naive context comparing tool might be a quick script that I could hack together relatively quickly; no patch theory necessary.)
Context files are certainly different from the DAG hashes that hg/git use and the auto-incremented numbers of cvs/svn, but I'm still of the opinion that the jury is still out on whether or not they are necessarily "harder"... Certainly context files will never be as "ubiquitous" as revision numbers/hashes, but I'm certainly not sure that is a bad thing.
-- --Max Battcher-- http://worldmaker.net _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
