[darcs-devel] patch for lazy partial repos

[Max Battcher]

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/