[darcs-users] Which commands can change output of darcs query contents for a particular hash?

[Max Battcher]

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