[darcs-devel] patch for lazy partial repos

[Eric Y. Kow]

On Mon, Apr 09, 2007 at 17:24:33 -0700, David Roundy wrote:
> Right, I just couldn't think of a better description than "lazy" for what
> we're doing.  It's not a very good name, since it's probably only
> meaningful to haskell programmers and CS folks.

Oh.  I hadn't thought of that.  Maybe something like --postpone-download

> > Perhaps it would be good if --lazy implied --partial and
> > --hashed-inventory
> 
> Yes, I thought about that and wasn't sure.  And am still unsure.

What might also be interesting is if --lazy were completely orthogonal
to --partial.  You know, lazy complete repositories which just avoid
getting patches until they have to.

> I'd prefer to always gzip them, but don't think it's a big deal.  In any
> case, the user should be able to change the option using optimize.

Yay! I was wondering why they weren't being gzipped.  Also, would it
make the code complicated to have the .gz extension on the patch
filenames?

> > Also, this mechanism suffers from a variant of --partial's leapfrog
> > problem (double get):

To be fair, how often do people actually do this?

> One option that could alleviate things would be to simply use symlinks or
> hard links when the url is local (i.e. has no ':' in it).  This might cover
> many such possibilities.

Well, I guess we could try to use hardlinks if it's local, with the
option of failing if it's a different filesystem, e.g. NFS mount.
Symlinks frighten me somewhat.  What if somebody moves the source repo?

Actually, would that be a source of concern for reading lazy patches?
One thing I've always liked about darcs's distributedness is the
inherent robustness. Somebody move the repo away? No problem, just
start pulling from elsewhere.  How would we deal with a file no
longer existing?

> That's definitely a danger, but in the cases where --partial works, which
> is read-only use or occasional development (with nothing tricky like
> examining all the patches), --lazy will also work just as well.  When
> --partial does not work, most users would prefer to download more patches
> rather than get an error message.

I could agree with that.

> It'd be a user-interace improvement (if optional), but I'm afraid it would
> *greatly* complicate the code (which is currently very simple).

Too bad.

To continue my random thought, I was thinking that it would be great if
partial repositories had some kind of checkpoint awareness, something
like:

   I need to retrieve 43 patches up to checkpoint
     2.0 stable
   Go ahead? [ynaq]

   I need to retrieve 132 patches up to checkpoint
     1.7
   Go ahead? [ynaq]


> > It might serve as documentation for a good chunk of these functions.
> 
> Even better might be a newtype.  It's more of a pain, but actually enforces
> the documentation.

I could live with that.  The pain might not be so severe if our
functions are just passing the paths/urls around and not trying to
match on them.  But I'm not sure how strong we want the typing on
stuff like this, in practice.  In theory, I'm for it.

-- 
Eric Kow                     http://www.loria.fr/~kow
PGP Key ID: 08AC04F9         Merci de corriger mon français.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070410/ab5976a7/attachment.pgp