[darcs-users] Which commands can change output of darcs query contents for a particular hash?
me at worldmaker.net
Fri Jul 10 22:43:05 UTC 2009
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
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
> 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.
More information about the darcs-users