On 1/9/07, Andy Levy <andy.levy@gmail.com> wrote:
>
> > Let me make this perfectly clear. I don't want or need this kind of
> > protection. I trust our empolyees. Always have and always will. Yes
> > we will probably get burned eventually. If this is the best argument
> > for using an SVN server, I don't need one. Anything else? :)
>
> Do you ever get audited? Got any ISO standards you need to meet,
> industry requirements, CMM, anything like that?
>
> Might you ever need to offer access to the repository to people who
> don't have access to the fileserver?
>
> Might you want to make portions of the repository available to people
> via a simple, read-only interface instead of having to use a
> Subversion client and full working copy?
>
> By using file:// access, *ANYONE* can delete the whole repository with
> a single errant keystroke. This isn't even about "trust", it's about
> mistakes. Stuff happens. Using svnserve or Apache, it's possible to
> delete the contents, but because it's a versioned operation, it's just
> as simple to undo the delete as it is to do the delete.
In addition to these reasons, has anyone discussed performance yet? I find
it hard to believe that svn:// protocol is not an order of magnitude faster
than file:// protocol when the repository is on a network share. The other
issue is that even though the fsfs repository format was designed so that it
could be used across many network protocols, I am not convinced that the
required file locking mechanisms needed are 100% reliable.
What reason would there be to not use svnserve or even Apache? I cannot see
why anyone would ever want to use file:// in a situation like this.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Tue Jan 9 15:07:05 2007