Sorry, my last post completely ignored the part about the file locking
mechanisms not being 100% reliable. Can anyone tell me for sure one way
or the other.
Brian
________________________________
From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Tuesday, January 09, 2007 9:07 AM
To: Andy Levy
Cc: Brian Erickson; Ryan Schmidt; users@subversion.tigris.org
Subject: Re: Re: Configuration files...
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:42:38 2007