[darcs-users] Which commands can change output of darcs query contents for a particular hash?
Nathaniel W Filardo
nwf at cs.jhu.edu
Wed Jul 8 19:34:00 UTC 2009
On Mon, Jul 06, 2009 at 01:53:20PM +0100, Robin Green wrote:
> 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?
The state of each file in the respository. There are multiple patch
orderings which might produce the same state, which is your real question.
> > , 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?
Yes, you understand my suggestion correctly.
The other half... well... That depends on what you mean by an earlier
revision (see below). But I would suggest that you express your desire to
darcs and get the file hash from darcs. This probably means that darcs
should have some mechanism for revealing the pristine hash of repository
files, as well as their context, given patch selectors, so that you can use
pristine hashes as keys to your cache.
> > 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.
Ah. Since patches might freely commute (consider, concretely, a patch which
only changed the first line of a file, and a patch which only changed the
last. At least if they stay next together [that is, there are other cases],
their order doesn't matter.) it probably isn't a good idea to use patch
hashes to describe file revisions.
To be pedantic, file revisions could be described by a set of patch hashes,
though not quite all subsets of all patches to a file make sense; we need to
say something like "if a patch is in the set S, all earlier non-freely
commuting patches [i.e., dependencies] must also be in the set". Since this
begs the question of "earlier", darcs resolves this in two ways: within a
repository, earlier means "present at commit time" and across repositories,
earlier is determined at "darcs apply" time by the context information
included in the applied patches.
This suggests, to me at least, that you are probably best served by using
date stamps as revision identifiers for individual files and asking darcs to
rebuild the state of that file as of that time.
On the other hand, any of my understanding could be faulty and I will yield
the floor to people more knowledgable. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the darcs-users