I'm not sure my expectations are realistic ;-) I'd hope for it to be
fast enough to use. I'm now looking into splitting up the repository,
but I'm meeting resistance on the whole move, so any changes like that
certainly do not help my cause. I tried the same thing on a comparable
linux box (in fact the server) and it took slightly under 2 minutes
rather than the 5 it took on the windows box, just for reference.
I assumed that update and commit were the same problem, as I understand
it they have to do the same evaluation for all the files, plus some
added work for the few files that actually changed.
As Shurik O points out, and I'm inclined to buy his numbers at face
value, CVS is twice as fast, even when it has to go to the server for
every file. Surely there's a fair bit of optimization that can be done.
Arni
On Nov 18, 2004, at 19:38, Ben Collins-Sussman wrote:
>
> On Nov 18, 2004, at 3:28 PM, Arni J Rognvaldsson wrote:
>
>> I'm trying to convert a largish vss repository to svn. As I'm sure
>> you understand, I can't stand working with vss. Not everybody feels
>> this way though, the lack of locking is a major roadblock, but the
>> time svn status takes on the repository is a show stopper. I'm using
>> version 1.1.1 on Windows, among other platforms. The repository has
>> 44k files in it, excluding svn's own files (202k of those...).
>> Running svn status takes about 5 minutes, which is just way too long.
>> I understand there may be a fix for this that did not make it into
>> the 1.1.1 version? If so, is there a 1.1.2 version in the works
>> anytime soon? I would build it from source but the Windows build
>> instructions look daunting.
>>
>
> There was a speedup patch committed on November 1st, but I don't think
> there's any patch that will make a difference to you. You're asking
> windows to stat() 44,000 files to look at timestamps, at a bare
> minimum. That's going to take -minutes- long, no matter how much you
> optimize away other disk i/o.
>
> The question is: what are you expecting, realistically? Certainly
> CVS would take just about as long, at least in the same ballpark.
> Maybe you shouldn't run 'svn status' at the very top of your working
> copy, but at selected subdirs further down.
>
> It may also just be a hindrance to have a working copy that big; 'svn
> update' and 'svn commit' are going to have to crawl over the whole
> thing, doing at least as much disk I/O as 'svn status'. Maybe you
> need smaller working copies of separate modules.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 19 20:52:18 2004