Re: Organizing repositories into hierarchy of directories at Apache's SVN root

On Apr 18, 2007, at 08:26, Andrew R Feller wrote:

> The largest, real concern is hitting the 2 GB limit. Other than that,

The 2-GB limit is per OS-level file. In an FSFS-based repository,
each revision is a file. So as long as you commit less than 2GB worth
of changes at a time, you wouldn't run into a problem. (See caveat
under backing up section below.)

> there are the typical concerns of storing everything in a single
> repository:
>
> 1. What happens when an analyst ends up checking out the entire thing?
> (They just learn not to do it again, IMHO)

Nobody should be checking out the entire repository. They should
check out only the part of the repository they're interested in. If
you serve the repository with apache2 and mod_dav_svn and install
mod_dontdothat then you can even prevent people from checking out
things that don't make sense, like the entire repository.

> 2. What issues are there with backing up large repositories?

If you try to svnadmin dump the entire repository into a single
dumpfile, then you could hit the 2GB limit, if your entire repository
is that large. To work around this, you could svnadmin dump a range
of revisions, then the next range, and so on until you've dumped the
entire repository. The choice of revision ranges will depend on how
big your revisions are and whether or not that range produces a
dumpfile that is too large. Or if you back up using a hotcopy, then
your backup is in itself just a repository, so there is no problem
there either.

> 3. What administration changes are needed for very large repositories?
> When do performance issues arise? What can be done to keep SVN
> responsive?

I can't offer any advice here as I only use Subversion for myself and
don't experience any performance issues.

Well, the one thing I can say is that Subversion works better with
fast disks and lots of disk cache (RAM). At least the client. Maybe
the server also. CPU speed is less important.

-- 
To reply to the mailing list, please use your mailer's Reply To All  
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org