Finally a reason I can get behind. The file:// access is SO much faster
that with PVCS I hadn't even considered performance. I'll look into
it...
>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.
For me, the only reason to set a svn server would be that the file://
access does not meet your needs. I don't care how easy an svn server is
to set up, it's more complicated than not doing it at all. If the
file:// access meets the needs, then adding an svn server does nothing
but create possiblities for problems.
If the file:// access is such a stupid thing to do it needs to be
removed.
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:40:38 2007