Re: Repository access woes

%% Ben Collins-Sussman <sussman@collab.net> writes:

  bc> Greg Hudson <ghudson@MIT.EDU> writes:

>> Please avoid sweeping generalizations like that one; a great deal of
>> large-scale use of CVS does not involve NFS in any way.

  bc> <rant>
  bc> I have to admit, I really don't care whether BerkeleyDB runs over NFS
  bc> or not. A BerkeleyDB environment is a far cry from a bunch of RCS
  bc> files with locks. It's a *database*. That means you should be using
  bc> a server, period. The fact that file:/// urls work at all is mainly
  bc> (1) an API sanity check, and (2) allows an individual user to keep a
  bc> private repository, when s/he may not have anything but a non-root
  bc> shell account.

  bc> But when you're talking about setting up multiple users to share a
  bc> database -- you've got to treat it seriously. There is no "just
  bc> create a repository and everyone pile on!" You set up a real server
  bc> process, with real authn/authz.
  bc> </rant>

Again, maybe I'm not following the details of the problem.

I'm in no way suggesting that you should not use a server; I would never
consider using SVN without a server, just like I would never consider
using CVS without a server.

However, in the corporate environments I'm familiar with critical data
is kept on a NAS system and accessed via NFS, _EVEN IF_ only one server
is accessing it.

That works fine with CVS. My understanding is that this won't work with
BDB. This, to me, is where the concern is. At least insofar as there's
any concern at all.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@nortelnetworks.com>   HASMAT--HA Software Mthds & Tools
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org