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

[Robin Green]

On Tue, 7 Jul 2009 19:01:12 -0400
Nathaniel W Filardo <nwf at cs.jhu.edu> 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