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

Re: Re: Configuration files...

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-01-09 15:06:43 CET

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