It seems to me that a repository holding a large number of large files
being accessed by a large number of people will present a bottle neck
of accessibility since it appears as though there is a limit of about
30-50MB/min of transfer out of the repository regardless the number of
clients. They all seem to share a slice of that 30-50MB pie.
So my question is, can a repository be distributed over several systems
to increase processing power? A cluster perhaps? I know that NFS
mounted filesystems can cause repository corruption so am not sure if
clustering would as well.
Another possible idea would be a central repository to act as the
Trunk, and additional repositories on separate systems to act as the
Branches. I am thinking of this being done in such a way that the
Branches are deltified off of the Trunk so as not to store redundant
information across the entire Tree of repositories...
There was mention in the archives of a method for running a
Master/Slave repository configuration where a change to a slave results
in that modification getting passed to the Master and subsequently
pushed back out to all the rest of the slaves. This method of seems
like it might be successful at distributing access to repository
information over several CPUs, but would likely fail for large and
frequent transactions to all Slave repositories, and stores information
far more redundantly than is truly necessary for safety reasons.
I am looking for a solution that will allow Branch development off of
Trunk, where each Branch has rapid and total access to its own
resources with out restricting I/O for the other Branches, and with out
excessive redundancy.
Any ideas on this?? Would something like this even be possible with SVN
in either its present or future incarnations??
-Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 24 22:35:01 2003