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
>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
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
From: Mark Phippard [mailto:email@example.com]
Sent: Tuesday, January 09, 2007 9:07 AM
To: Andy Levy
Cc: Brian Erickson; Ryan Schmidt; firstname.lastname@example.org
Subject: Re: Re: Configuration files...
On 1/9/07, Andy Levy <email@example.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
Do you ever get audited? Got any ISO standards you need
industry requirements, CMM, anything like that?
Might you ever need to offer access to the repository to
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
Subversion client and full working copy?
By using file:// access, *ANYONE* can delete the whole
a single errant keystroke. This isn't even about
"trust", it's about
mistakes. Stuff happens. Using svnserve or Apache, it's
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
Received on Tue Jan 9 15:40:38 2007