Re: Best Practices: Performance on Large Repositories?

Steve Seremeth wrote:

> 1. Expected "ballpark" performance information would be very helpful in
> the FAQ. Other SCM systems might not be any better on this front, but
> if we had known upfront what this was going to be like we might have at
> least organized our repository (and subsequently, our build scripts)
> differently.

The only thing I can think of is that a lock/unlock SCM might be able to
assume that files which you did not lock cannot be modified, so it would
have less to scan. Of course, if it made this optimization, it would
silently miss anything that you edited locally when you weren't supposed
to.

> 2. Is reorganizing the repository so we can be working on smaller
> pieces the only answer to this problem? Is there a size of repository
> that is just _not_ recommended for use with Subversion?

No, the other choice is to pass the --non-recursive argument, or some
paths/files, or similar to the svn commands to restrict what portions of
the WC they have to look at. Otherwise they have to look at everything,
which is inherently rather slow if you have a giant WC.

> Thanks -
>
> Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 17 05:29:15 2005