RE: SVN Security

On Sun, 2005-07-17 at 12:28 -0400, Calvin wrote:
> Right, again, need a Linux machine for this. :-)

Probably an excellent idea. SVN runs on both, but Windows installations
are constrained more by their environment as pointed out by Marc

> Maybe I need to look for a professional SVN hosting with state of art
> environment to make sure everything runs fine. 500,000 revs should be enough
> for my any near future concerns (5 - 10 years later? We will have new system
> anyway).

Another excellent idea. If you do not have the knowledge to do
something yourself, pay someone else to do it for you who does.

> Another concern is performance. I keep seeing the word "time out" when I
> read the book. The word "wedge" keeps me away from bdb, but the "time out"
> is also scary.

I searched for the string "time out" in the 1.{0,1} book. Zero hits.

"timeout" returned configuration values in the client that allow it to
return saying the server it is trying to contact is down.

This is the same reason in the table for FSFS, the transaction takes
longer to process in the new file system, so therefore it is possible
that the timeout values described above could be reached. Therefore
increase them if you see these problems (I doubt you will).

> When you check out a repository or commit a change, is SVN smart enough to
> keep this operation a constant time frame, disregarding how many revs you
> have? I feel like SVN has to re-calculate everything from rev0 in order to
> reach the final state of every file in the repository.

There is no such thing as a "constant time frame" for commands in
subversion beyond 'copy' since network traffic is normally
non-deterministic.

SVN is not a real time system (neither hard nor soft) and the length of
time of an operation is dependant on the sub-command you invoke (ie,
checkout, merge, status, etc.) also if the command needs to contact the
repository or can do the command using only the local working copy.

Commands are also dependent on the size of the changes you make.

> Anyway, I like the FSFS approach, but the scalability is a real concern. I
> am wondering why it's not a concern when the approach is decided, as it's
> easily to partition the files in to a decent hierarchy folder structure
> without too much work.

Patches are always welcome, so are recipes to create the scaling problem
you describe. This is community effort, not a tyranny.

Cheers,
Chris

-- 
PGP Public Key: http://www.nesser.org/pgp-key/
15:08:03 up 22:01, 2 users, load average: 0.62, 0.57, 0.45