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

Re: Multiple vs Single Repositories

From: Andreas Hasenack <andreas_at_conectiva.com.br>
Date: 2007-05-02 20:33:14 CEST

On Wed, May 02, 2007 at 01:25:09PM -0500, Irvine, Chuck R [EQ] wrote:
> We have a very large number of applications. Our current plan is to have
> just one SVN repo with a structure like:
>
> Repo/
> app1/
> trunk/
> branches/
> tags/
> app2/
> ...
>
> In total, I'd say we have well over a 100 active applications. However,
> I'm getting a little nervous about the possibility of a repo corruption
> causing all of our application teams to lose SVN access. So, I'm
> wondering if a better approach would be to have each application, more
> or less, in its own repository.
>
> I'm curious to know the communities opinion on this in general.

It could make sense to create a few repositories and store them in
separate disks. Note that there will be an administrative burden because
you will have more hooks and acl files to deal with, and possibly
authentication mechanisms depending on what you are currently using.

One repo per app in your case I would say is overkill.
 
> Also, if a repo corruption does occur would it usually be isolated to a
> single application, or do corruptions often affect the entire repo?

Depends on the cause of the corruption. I had a filesystem corruption a
while ago and it affected all directories in the repository.

> Finally, in general how common are these repo corruptions? I see reports
> of them on the mailing list, but perhaps they are really very uncommon.

I believe most are caused by faulty hardware or filesystem corruption,
and not specific svn bugs.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 2 20:33:39 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.