On Tue, 7 Jul 2009 19:01:12 -0400 Nathaniel W Filardo <[email protected]> wrote:
> 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 What do you mean by a repository "configuration"? A patch ordering, or the states of each file in the repository? > , 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. If I understand you correctly, that would only be applicable for the most recent revision. What about earlier revisions? > 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? If a specific revision was not requested, that means that the in-some-sense "most recent" revision will be provided. > Are you identifying revisions by timestamp? No, currently we identify them by patch hash. -- Robin _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
