[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Re: Configuration files...

From: Brian Erickson <erickson_at_BAUERCONTROLS.com>
Date: 2007-01-09 15:40:09 CET

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: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.

        Mark Phippard
Received on Tue Jan 9 15:40:38 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.