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

Re: permanent solution for deltification problem (issue #1601)

From: Ryan Hunt <rhunt_at_hp.com>
Date: 2003-12-04 19:35:21 CET

On Dec 3, 2003, at 3:44 AM, Mike Mason wrote:
> I do commits against an 8,000 file repository, changing maybe 300
> files, over a lan, and the (deltification) delay after it's finished
> printing little network progress dots can be 2 or 3 minutes, which is
> roughly 4 or 5 times the time taken to transmit network data. The
> "think time" before starting to transmit is also quite large, but
> that's all on the client and with a big repository is to be expected.
>

Just thought I would give a little feedback on my end. As a
user/administrator I am not as concerned with the default as I am with
the ability to configure my things how I want.

One of the big draws for me is the large binary file handling
advertised for svn over other scm. I am sure that as time goes on that
more and more people that are looking for ways to version large binary
files will turn to svn...

If that is the case IMHO it would be best to plan for that now.

My repository is currently 107GB with 339 commits, approximately 4000
files. Files frequently approach 500MB-1GB.

I have been at an impasse for a while because of this deltification
issue. Everyone on the list seems to be talking of 2-10 min delays, in
my situation deltification frequently causes delays up to 4 hours or
more. This is definitely something I would want to run as a nightly
cron or as weekly maintenance schedule.

Any thoughts?

-Ryan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 4 19:32:33 2003

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.