Bazaar Subversion Plugin

caching should be enabled for file:// urls that point to network shares/NFS locations

Bug #491806 reported by Kuno Meyer
This bug report is a duplicate of:  Bug #520694: decent cache format. Edit Remove
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar Subversion Plugin
Incomplete
Undecided
Unassigned

Bug Description

This is a fairly low-prio request; but, it took me some time to find a solution. Therefore, to save other's time, this bug entry:

bzr-svn doesn't seem to cache revision information for repositories accessed through the local file system. I guess, this is due to the incorrect assumption that file access for local file paths is fast. But this must not necessarily be true if the file location effectively is a network share/NFS mount.

Therefore, my suggestion is to enable caching also for local (= "file://") repositories if they are on a network share/NFS mount (... if this information is available through the Python standard library).

Revision history for this message
Jelmer Vernooij (jelmer) wrote :

Have you actually done measurements that prove that the cache will help the performance? Unless the round-trip time to the NFS server is close to a second I don't think the overhead of the cache would be worth it.

Changed in bzr-svn:
status: New → Incomplete
Revision history for this message
Kuno Meyer (kuno-meyer) wrote :

During the "analyse repository layout" phase, bzr-svn reads all files in "db\revs\" and "db\revprops", starting from the latest revision down to revision 1. This means that there are O(# of SVN revs) roundtrips, which is very costly even for small repositories.

The effect of caching is therefore easily perceptible (although I didn't measure it): "bzr update" for a bound branch of a repo with ~120 revs takes >30-40s in the non-cached case, but ~4s with caching...

Ironically, I couldn't bring bzr-svn to branch from a SVN repo URL with a drive letter in it (file:///x:/somewhere), only nonlocal or network-visible names (file://server/share/repo) were accepted. But that use-case might be more important for testing than in production use.

Revision history for this message
Jelmer Vernooij (jelmer) wrote : Re: [Bug 491806] Re: caching should be enabled for file:// urls that point to network shares/NFS locations

On Thu, 2009-12-10 at 18:02 +0000, Kuno wrote:
> During the "analyse repository layout" phase, bzr-svn reads all files in
> "db\revs\" and "db\revprops", starting from the latest revision down to
> revision 1. This means that there are O(# of SVN revs) roundtrips, which
> is very costly even for small repositories.
 To determine the repository layout it does this only for the last 400 or
so revisions.

When using a cache, it has to walk over all revisions anyway to fill the
cache. Accessing the cache also requires disk access as well as some
access (although less) to the repository itself. It also uses extra disk
space in the users home directory.

Furthermore, the cache is stored in the users home directory, which may
also be on NFS.

> The effect of caching is therefore easily perceptible (although I didn't
> measure it): "bzr update" for a bound branch of a repo with ~120 revs
> takes >30-40s in the non-cached case, but ~4s with caching...
I strongly doubt this; I'm willing to be convinced to change the
heuristics that determine whether to use the cache but please suggest
benchmarks and suggest better heuristics.

Cheers,

Jelmer

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.