[darcs-users] [darcs-devel] [issue992] short secure version identifiers

Nathaniel W Filardo nwf at cs.jhu.edu
Wed Aug 13 09:01:35 UTC 2008


On Tue, Aug 12, 2008 at 11:32:04PM -0400, Max Battcher wrote:
> Zooko wrote:
> > New submission from Zooko <zooko at zooko.com>:
> > 
> > My Primary Canary is Brian Warner.  He is the most important person for me to
> > work with, and if he is not happy with darcs, then I'm not happy.
> > 
> > Last November he wrote this letter:
> > 
> > http://allmydata.org/pipermail/tahoe-dev/2007-November/000228.html
> > 
> > The parts about performance are still an issue (he recently said, when I asked
> > him, "I would like it to be faster."), but this ticket is about the other part:
> > short, secure identifiers for versions.  I recently asked him to clarify exactly
> > what he wanted:
> 
> Hey Zooko, thanks for the report.
> 
> Just out of curiosity, does he know about context files?  If so does he 
> not find them sufficient?

Since presumably "short, secure version identifiers" are meant to be a
reference to a configuration that somebody else built, not some arbitrary
subset of patches in the pool, would it suffice to have darcs
{record,push,pull,show version,...} create a context file for the new
configuraton by default?

If darcs stored these in _darcs/contexts/${HASH} using some baseN encoding,
then they are
  1) tradable as context files in their own right
  2) a cache which may be pruned (almost arbitrarily) if so desired
  3) O(1) to access assuming cache hit
  4) "cheap" to generate at the time (O(patches-since-last-tag)?)
  5) With high probability globally unique.
  6) Identically generated by multiple repositories with the same contents.

Granted, if there's a cache _miss_, it's O(2^n) or worse to reconstruct
contexts.  This can be made a little more palatable if the last tag is
inserted into the hashed name so that we can bound below[1] the search space
if we have to... so what if it was
"_darcs/contexts/${LAST_TAG_HASH}-${CONTEXT_HASH}" with the former being say
64 bits (11 base62 characters) and the latter being 128 bits (21 base62
characters).  All told 34 characters of version...  longer than hg's
default, but probably still sufficiently compact (cf.  msg5441).  Moreover
including the ${LAST_TAG_HASH} would give a nice way of knowing what was
"likely safe" to remove from the cache, perhaps.

Thoughts?
--nwf;

P.S. If one actually adds a "darcs show version" command, it ought to stick
"+" or something at the end (ala hg) to indicate that there are local
outstanding changes in managed files.

[1] (and above, potentially, or at least issue a warning of the form "I didn't
find this in the fast path; hit Ctrl-C or the universe might end before this
computation" ;) ) 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20080813/45b9365b/attachment.pgp 


More information about the darcs-users mailing list