1 patch for repository http://darcs.net:

Sat Apr 17 03:56:44 MSD 2010  Dmitry Kurochkin <dmitry.kurochkin@gmail.com>
  * Resolve issue1159: smart caches union.
  Try to do better than just blindly copying remote cache entries:
  
  * If remote repository is accessed through network, do not copy any cache
    entries from it. Taking local entries does not make sense and using network
    entries can lead to darcs hang when it tries to get to unaccessible host.
  
  * If remote repositoty is local, copy all network cache entries. For local
    cache entries if the cache directory exists and is writable it is added as
    writable cache, if it exists but is not writable it is added as read-only
    cache.
  
  This approach should save us from bogus cache entries. One case it does not
  work very well is when you fetch from partial repository over network.
  Hopefully this is not a common case.

Attachments

• resolve-issue1159_-smart-caches-union_.dpatch
• unnamed

Could you have a look at this, Florent?
Adolfo, you should probably see what's going on as well :-)

This patch bundle (with 1 patches) was just applied to the repository http://darcs.net/.
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__darcs.net_.html#bundle-abc2218c19f644f81093d2733c52f2294780d934

Dmitry Kurochkin <bugs@darcs.net> writes:

> Sat Apr 17 03:56:44 MSD 2010  Dmitry Kurochkin <dmitry.kurochkin@gmail.com>
>   * Resolve issue1159: smart caches union.
>   Try to do better than just blindly copying remote cache entries:

>   * If remote repository is accessed through network, do not copy any cache
>     entries from it. Taking local entries does not make sense and using network
>     entries can lead to darcs hang when it tries to get to unaccessible host.
(see below)

>   * If remote repositoty is local, copy all network cache entries. For local
>     cache entries if the cache directory exists and is writable it is added as
>     writable cache, if it exists but is not writable it is added as read-only
>     cache.

>   This approach should save us from bogus cache entries. One case it does not
>   work very well is when you fetch from partial repository over network.
>   Hopefully this is not a common case.
I think this is a problem. Oftentimes, people won't realise a repository
is partial and publish it. This used to work transparently and I think
that was a good thing. The right fix for the problems you mention is to
check for usability of sources and complain to the user.

Either something like:

Warning: Host 1.2.3.4 is unreachable.
Remove from list of source repositories? [yN]

Warning: Hostname foo.bar.baz cannot be resolved.
Remove from list of source repositories? [yN]

Alternatively (this is probably better):

Warning: Host 1.2.3.4 is unreachable. Maybe we are offline? However, it
may also be the case that this address is bogus, in which case you
should remove it from _darcs/prefs/sources. This will speed up darcs.

Another possibility (this is probably best):

Honour the order of the sources lines. If a host is unreachable or
directory does not exist, move it to the end of sources. This would
prevent almost all issues automatically, without losing any data or
losing any existing features (transparent support for partial networked
repositories, eg.).

Yours,
   Petr.

On Wed, Apr 21, 2010 at 13:37:18 +0000, Petr Ročkai wrote:
> >   * If remote repository is accessed through network, do not copy any cache
> >     entries from it. Taking local entries does not make sense and using network
> >     entries can lead to darcs hang when it tries to get to unaccessible host.
> (see below)

> I think this is a problem. Oftentimes, people won't realise a repository
> is partial and publish it. This used to work transparently and I think
> that was a good thing. The right fix for the problems you mention is to
> check for usability of sources and complain to the user.

First, I notice that this patch was superseded by patch215 which was
applied.

Second, until we implement something like Petr suggests, how about
copying *just* the network entries if the remote repository is accessed
through a network?

In any case, for the local entries it seems like deleting them is better
than what we did before.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

This patch bundle (with 1 patches) was just applied to the repository http://darcs.net/reviewed.
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__darcs.net_reviewed.html#bundle-abc2218c19f644f81093d2733c52f2294780d934