Nathaniel W Filardo wrote:
As far as I understand darcs' patch theory, --match=hash is not a stable way
of identifying a repository configuration, nor (by extension) a file state.
It may be an unstable way of identifying some (not necessarily proper)
superset of that patch's minimal context (that is, every time you use
--match=hash you'll get some superset of the minimal context), but that
probably isn't what you wanted.
Indeed. I've strongly mentioned the fragility of --match "hash" for
identifying revisions: not only are patch hashes semantically
meaningless to human beings, but in darcs patch != revision. In fact, I
think the correspondence between patch-matched subsets and meaningful
revision states.
It's been one of my biggest complaints with both Darcsweb and Trac+Darcs.
I want to make sure that, even if the actual repository history is
being "rewritten" due to patch reordering, the users can at least *see*
a representation of how the history *currently* looks, rather than
being stuck with some cached version of some revisions and some
up-to-date version of some other revisions, which could lead to
inconsistencies such as the same textual change appearing to happen
twice.
Your best bet is probably to not try to decode the patch theory yourself but
read out from the pristine index the hash of the file as it exists in the
current configuration and use that as your cache key. It might not hurt to
give darcs a command to report these, to save you the effort of writing code
to parse _darcs/pristine.hashed.... with the Gorsvet/hashed-storage backend,
you could just use hashed-storage to do the parsing for you.
I've got a partial implementation of this myself in my "darcsforge"
code. The pristine object names/hashes as cache keys seems a useful tool
for caching historical data. Dealing with new integration states (er,
revisions) is easy (during a cache walk through pristine), and I was
fretting how to deal with historical integration states but just
recently had some ideas involving context file caching.
I certainly think that modeling revision tracking around pristine.hashed
is the current best way forward. I do feel for those that haven't thrown
out the bathwater and trying to shoehorn such a solution into a
traditional revision number/hash-based design. I think gitit would be a
different animal if it were designed with darcs in mind from the beginning.
--
--Max Battcher--
http://worldmaker.net
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
