[darcs-users] Revised storage disciplines (was: Re: cheap in-repo local branches (just needs implementation))

[Nathaniel W Filardo]

On Wed, Jul 22, 2009 at 08:56:00PM -0400, Max Battcher wrote:
> Certainly one possible solution here would be to simply carry over the  
> Hash: lines from the darcs-2 inventory format as (optional) hints for  
> file paths in context files. Considering the otherwise congruency of the  
> context and inventory files I would hope this might be something easy to  
> achieve (and would be useful generally), and I'm hoping the reason it  
> hasn't been done is simply because it hasn't thought to be done.

While we're talking about revving the storage, would it be feasible to
switch _all_ references to patches to be by hash only?

This would, I think, have several advantages:

  0. It reduces duplication of patches and sets both storing all the
     user-supplied patch information.

  1. It's more in line with CAMP theory in that we can now concretely
     give secure, globally unique names to every small patch object
     (e.g., addfile, hunk) to every revision of a titled patch object 
     (i.e., collection of small patches).

  2. It could be a first step towards addressing Zooko's recently
     raised concerns about being able to dupe darcs about patches.
     The context files now really do securely describe exactly a set
     of patches to be applied, rather than a set of representatives
     from equivalence classes from which another representative might
     be used instead.  This seems to play well with issue992.

  3. It might also be a first step towards allowing superceders, since
     it means that darcs is pointing not at "any one of an equivalence
     class" but at a particular element of that equivalence class.
     (Superceders are an under-developed mechanism for doing "safe
     amend-record".)  That is, going hash-centric makes it possible to
     say things like "this hash replaces that hash".

Of course, upon receiving a context or list of objects represented this way,
the current equivalence classes would still need to be calculated by opening
the object by hash and reading the patch info.  That doesn't seem too bad...
it might be a large number of file opens until hashed-storage indexes things
this way? (I was under some impression that it was going to; if that's
mistaken, please let me know.)

Thoughts?
--nwf;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090723/24630bb5/attachment.pgp>