Also windows starts being very slow when you have a lot of entries in a
directory. I think you are hitting that problem. Perhaps in the future
SVN can be designed to keep a nested directory structure, keeping no
more then X revisions in a folder. Basically something like this
revs
1/
1
2
3
...
99
100
2/
101
102
etc. I'm sure there's a better way to implement this though, but I
think this is definitely needed for large number of revisions on windows.
Russ
Ruslan Sivak wrote:
> Hmm... I know some windows filesystems have issues with files over
> 2GB... are you on FAT32 by chance? I think NTFS should be able to
> handle it.
> Also I wouln't run your server on windows if I had a choice. All our
> servers are windows except the server we use for SVN (and a few other
> things). In general linux is just going to be more stable, and I
> believe doesn't suffer from the 2gb limitation (correct me if I'm wrong).
>
> Russ
>
> John Thile wrote:
>> Hi Garrett,
>>
>> Again, thank you for the prompt response!
>>
>>> Note that the ideal situation for large file support in svn is using a
>>> recent build of APR from the 1.2.x series of releases. 0.9.x is hit
>>> or miss.
>>
>> Hmm, okay -- with what version of APR are the official, pre-compiled
>> binaries built? I'm using the pre-compiled Windows binaries for SVN
>> 1.3.2.
>>
>>> Neither is "preferred", they both have their advantages. The protocol
>>> used with svnserve is indeed faster in many cases, but the Apache
>>> based server is more flexible in many ways and provides some
>>> capabilities you can't get with svnserve today. It also works over
>>> http and thus you often have fewer firewall problems with it than
>>> you'd get with svnserve and its custom protocol.
>>
>> Thanks for the feedback. I will seriously consider switching to
>> svnserve, in this case. My users are going to mutiny if performance
>> doesn't improve, somehow! ;)
>>
>> Thanks,
>>
>> John Thile
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 6 21:34:43 2006