[darcs-devel] Re: [issue498] progress indicators

[Tommy Pettersson]

On Sat, Jul 21, 2007 at 11:06:21PM -0000, Kevin Quick wrote:
> Questions:
>    * I looked back over the reflector mail, but I'm afraid I'm still
>      a little foggy over the new HashedRepo format and how it's
>      different from the old- style DarcsRepo. And particularly, how
>      is it valid to cache patches for a HashedRepo in a manner that
>      avoids the above problem for DarcsRepo-style patches?

As far as I understand it, hashes in the hashed repo include the
patch content too, so every different commutation of a patch has
its own hash number (and file). Therefore if a file with the
right hash already exists, it must be not only the correct patch
but also the correct commutation of that patch.

This results in darcs having to store the hash values in the
inventory, as a patch changes hash value (and file, where the
contents is stored) when it commutes.

>    * Does the caching sound interesting enough to warrant resolving
>      the above issue in some manner, or is the suggested workaround
>      above the simplest and recommended way to handle this?

David has implemented lazy fetching of patches (for partial
repos only, I think). The idea is that when we can't find a hash
among our patches we automatically fetch it from the remote
repo, i.e. we complete one more part of a previously partial
pull.

There has been talk about having local "patch pools" (instead of
linking patches between repos), so that if one local repo
fetches a remote patch, it will end up in the local pool, and
all other local repos that later pull that patch will find that
it's already in their possession.

It think this might be close to what you want, or at least give
you some more ideas.


-- 
Tommy Pettersson <ptp at lysator.liu.se>