[darcs-devel] patch for lazy partial repos

[Kevin Quick]

IMHO, good question, Max.  I had the same question, only adding
_darcs/prefs/repos as well.

To amplify (at the risk of simply restating Max's comments):

1) A lazy, "not-here-yet" patch would not contain the url, just a
constant keyword (e.g. "NOTFETCHED").
    a) For that matter, why does it even need a file?  The inventory
         says it should be there, so if it's missing, it's just assumed
         to be a lazy "not fetched yet" patch.

2) When darcs *needs* to read that patch and sees NOTFETCHED, it
first tries to get it from  _darcs/prefs/defaultrepo, and if not
found, it then iterates through _darcs/prefs/repos until the patch is
found or all is exhausted.

  a) In the latter case, darcs generates a message:
      "Could not get patch 'xxx'; please darcs pull from a source
repo that contains this patch."

  b) When pulling from a repo, that repo might also just have the
      NOTFETCHED version of that patch

       i) Perhaps darcs should also fetch
           _darcs/prefs/repos from that repo and nub add it to
           _darcs/prefs/lazyrepos, which is the third scan list for
           finding lazy patches....

  This helps sidestep the issue of "the source can never move" to a
degree, and if the source does move, a darcs pull from another repo that
has that patch makes them available again.

3) Also, perhaps commands like "darcs changes -v" that might ordinarily
need to fetch all the patches could instead (for a lazy repo), exit at
that point with a message like:
"[possibly more in remote source repos; use --fetchall for a full list]"

That way, a user's normal work would only work with the patches locally
available (which they'd want, given that they'd gotten a --lazy pull),
and they would actively tell darcs that it was OK to possibly take more
time and fetch the lazy patches.

   a) Maybe the --fetchall is always required, and any command that
       runs into laziness incompleteness would generate either
       i) a standard warning (like above),
      ii) an error, indicating that the option was aborted because a
          NOTFETCHED patch was needed and --fetchall was not given,
     iii) a message like Eric is proposing that indicates a fetch is
          needed and asking if it's OK to do right now.

Note that I like both --fetchall and an interactive response; the
former allows the directive to be given up front so that you're not
"surprised" by the different question (e.g. after answering y or n for
47 patches on a pull, your n doesn't suddenly mean "no, don't fetch
from remote"), but the latter does allow you to only decide if/when it's
necessary.

-KQ


 On Tue, 10 Apr 2007 18:42:41 -0400, "Max Battcher"
<me at worldmaker.net> wrote:

> This may be completely off the mark, I'm entirely ignorant of how
> partial repositories work (and I've not had the reason to work with
> one thus far), but does darcs need the "url symlink" patches anyway?
>
> Why can't darcs just take on the lazy behavior whenever a patch just
> doesn't exist or is perhaps an empty file or some other similar
> thing...  ie, in that changes -v when it needs the information in a
> patch and the patch isn't available couldn't it just attempt an
> auto-pull of that patch from _darcs/prefs/defaultrepo, unless some
> alternative is specified in an argument?
>
> Basically, instead of hard-coding "this patch can be found at URL" why
> not figure that out just as you would in the get or pull based upon a
> provided URL or the defaultrepo pref?
>
> I'm guessing the problem here then is a little tougher because every
> command that might have a side effect of "fetch more patches" such as
> changes or what have you will need to pass around a bit more info
> (repository to pull from in case of a late download of a patch), but
> it seems that some sort of flag of this nature was bound to pop up
> anyway only instead of adding a --no-late-downloads flag to commands
> like changes -v this would imply something more like a
> --late-patches-from=repo flag instead.  I would think this might even
> work for existing partial repositories to grab additional history as
> needed... where a command might have failed in the past you could
> instead just apply the new flag to download any additional history
> required.
>
> Anyway, apologies if that doesn't make sense to the internals of
> darcs...  but it seems to me like the above is the "easier",  or at
> least more powerful solution, because with URLs in the patch file you
> lose a lot of flexibility and would probably need a command or two
> eventually to "rebase" those URLs or similar.
>
> On 4/10/07, David Roundy <droundy at darcs.net> wrote:
> > I thought about that, but a lazy complete repository would always be unlazy
> > (all the patches downloaded) by the time the get is completed.  On the
> > other hand, a lazy complete get would be resumable by running repair.
> > i.e. if darcs dies before all the patches have been downloaded, you could
> > just run repair to finish downloading the rest, so that's not a bad idea...
> >
> > We could potentially introduce a get --resume (or resume get?) which
> > effectively does a repair and a revert --all.
>
> That does sound like it might be useful, and a resumable get might be
> something to aspire to by default.
>
> --
> --Max Battcher--
> http://www.worldmaker.net/
> _______________________________________________
> darcs-devel mailing list
> darcs-devel at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel


--
--
Kevin Quick
quick at org after sparq
-------------- 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-devel/attachments/20070410/98f7972d/attachment.pgp