On Mon, Aug 24, 2009 at 01:50:11 -0400, Nathaniel W Filardo wrote: > > Note the file hash ties us to a particular instance of a patch. If we > > commute the patch, it gets a different file hash so I don't think this > > would give us enough information to work with. > > Correct. However, context files always contain a given linearized > representation of the dependency graph and therefore may get away with > refering only to one particular commuted form of a patch.
But the issue is that the repository against which you are applying the context may not have the same linearisation as you do. So what I'm saying is that if I have repository <ep1 ep2 ep3> and you give me context <np2 np1> ie a subset of my repository in a different order, I ought to be able to use it without looking at your repository. Incidentally, I still don't know how this works in the current Darcs. I imagine that we just have straightforward traversal walking down the Nathaniel context file and for each n-patch, seeing whether I can commute the corresponding e-patch to the head of the list. > > The problem with using just the file hash is that the object you want > > may just not be on the repository you're reading from. You may be able > > to reconstruct it through commutation, but then you'll need the regular > > patchinfo stuff to do that. > > First off, it's probably rude of me to send you a context file and a pointer > into my repository for which I am unable to provide the backing store. Not at all! I think the whole point of context files is that the recipient does not require access to the sender's backing store (does that just mean the patch files?), but that you can rely on the property that a set of patches in any order permitted by commutation gets you the same repository. So it shouldn't matter if my patches are out of order with respect to your context; as long as I can commute my history to your context, we're fine. This kind of thing allows me to darcs get --context=nathaniel eric even if the two repositories are not necessarily in the same order > Secondly, there's no check currently that two patches which are decorated > with the same patch info are actually different commuted forms of each > other. This is Zooko's point about the failure of security in darcs -- it's > possible to provide you a bogus patch that looks right. Switching to hashes > as identifiers closes the bogus-return hole at the expense of requiring > either more time (to generate a locally relevant context file) or space (to > store all the different commuted forms of a patch). Right, I don't dispute that hashes in contexts are useful; I just think that relying exclusively on them is not going to work out. As an aside, I guess the security risk is a bit more obscure in the darcs get --context=you my-repo scenario, in that what could go wrong is that you fool darcs into thinking that two patches commute when they really shouldn't, i.e. doing evil things without touching so much the patches but their order. > As an alternative proposal, since commutation is going to alter the content > of a patch -- but merely its place, rather than real "content" -- we could > instead give each file a unique identifier (other than its name; cf. > arch/tla) and discard positional data of hunks when hashing the patch. Such > an identifier should be unmolested by commutation and may therefore stably > name a patch; at least one set of location data would have to be provided in > order to commute such a thing, but that's probably OK. This feels similar > to http://web.mornfall.net/blog/patch_formats.html . I'm not sure I understand the proposal. Superficially, it sounds like how darcs 1 names its patches, using the patch hash rather than the file contents hash. If this is the case, note that it doesn't have the nice property of associating each file with a hash so you would have to reinvent one with some sort of table. Max suggests using both hashes which I suppose will work, but then I'll just throw up a different kind of grumpy resistance :-) which is that I personally have a strong preference for things to be as humanly readable as possible even if it's not technically necessary. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
