On Mon, Jul 06, 2009 at 04:33:13AM +0100, Robin Green wrote: > However, I know that darcs' patch theory allows patches to be > reordered. This could mean that the output of darcs query contents > "--match=hash foo" could vary over time - or have I misunderstood? Then, > if that's the case, which commands might potentially cause this output > to change? i.e. could a push into the repository cause this to happen? > Or would it require some other command, such as obliterate? (It's fairly > obvious to me that obliterate could cause this to happen, because you > could obliterate an earlier change to a different part of the same > file. Right?)
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. It's possible that no commands, but subsequent reindexing of the repository patch set would change the order... consider if darcs did start computing and using minimal contexts internally (it currently doesn't). > 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. How are you naming "revisions" in gitit? That is, when you say > 0. If a specific revision was not requested what is the alternative? Are you identifying revisions by timestamp? Context files? Sets of patches? Something else? --nwf; ----- End forwarded message -----
pgptSoc43fuoS.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
