<?> Capacity Question: How Does Size Matter <?>

Howdy,
 
I am administering a reasonably sized repository and I'm new to this SCM
tool. I have read the red bean book, but I am wonder if anyone has actual
experience with subversion handling large repositories.
 
I have about 40 users and three project branches (each with a 3-5 GB
mainline and tag branches). I am planning to move from a scenario where all
users work on the mainline to one where users work in private branches and
their changes are promoted to the mainline through a verification process.
 
The majority of my users will work on two projects at most, which means
their private branches will each have one or two view of the mainlines. I
had planned on some kind of automated scheme to keep all of the private
branches updated with changes from the mainline projects.
 
Question 1: Lazy Copies, do they remain lazy when the branch is updated from
the original mainline?
I can see that this may add considerable girth to my environment.
I understand that svn does a lazy copy when making a branch.
By this I mean that the new branch merely references the original
file, until that file is changed on the branch. If I change the file on
the branch, a delta must be placed in the branch.
If I update the branch from the mainline, does svn create a delta
or does it lazily use the delta from the mainline?
E.g.,
Main is branched to create Private at revision 2
Main/Foobar.cpp is updated as revision 3
Main/Foobar.cpp is merged over the Private as revision 4
 
Main has an original Foobar.cpp and a delta that allows
it to reach revision 3.
 
Does the Private branch have an additional delta or does
It just use the aforementioned one?
 
 
Question 2: Does any one know what the upper limits are to repository size
and what is recommended to deal with them?
 
Question 4: Beyond the unused dblogs are their other maintenance practices
that can improve performance?
 
Question 5: Do any of you run the http access and the customer svn protocol
(svnserve)? If so have you noticed a difference in performance?
 
Thanks, any information would be greatly appreciated.
 
 
            
 

--
Peter Kahn
pkahn@connected.com