[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

The sometimes false economy of local WC pristine copies

From: Travis P <svn_at_castle.fastmail.fm>
Date: 2005-03-25 18:57:41 CET

When a copy is on a network volume, then saving network traffic by
keeping a local, pristine copy in the WC doesn't work. It may even make
things worse (both the penalties of large storage requirements + large
network traffic are paid). All the network traffic is there (between
local and AFS server rather than local and Subversion server if there
were no such pristine copies), plus svn is using it's tmp directory too
freely assuming it is cheap.

Some data points on a Linux system of a ~42 Mb, or only ~1000 files:
* local, very close to 1 sec (consistently)
  * AFS with svn:eol-style=native on all text files, a little bit over
60 sec (consistently -- after the first time and the AFS cache is warm;
first time was 86 sec)
* AFS with no svn:eol-style or svn:keywords properties on all text
files, a little bit over 6 sec

Two thoughts here:

[1] svn should recognize when svn:eol-style is set to native and native
matches the internal repos representation ("\n" right?) that it doesn't
need to do anything (i.e. both my AFS timing's above /should/ be 6
sec). I imagine that this optimization might not be too hard. (I
cannot contribute any patches or code myself at this time until I go
through the rigmorale of getting permission from my employer.)

[2] Another potential optimization: use the system supported
TMPDIR/"/tmp"/%TMPDIR% (or whatever Window's calls it) rather than the
.svn/tmp directory for files that don't need to be moved atomically
into place. That way, all those files (which is probably the great 6
sec -> 60 sec slowdown I found), can be accessed locally even if the WC
is on a network store.

[3] For cases like I detail here plus significant other cases that
users have presented (especially those involving large media files),
keeping a local pristine copy just is not efficient. A smart
'rsync'-like efficient protocol of dealing with server-held pristine
copies is the way to go. For WC copies on AFS volumes, the WC will
never be worked on in "disconnected mode" anyway. I realize this is a
long-term goal already. I'm just showing another usage example where
it is pertinent in case you thought this only affected people working
with large media and not software development houses with relatively
small WCs.

-Travis Pouarz

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 25 18:59:24 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.