You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/08/18 23:22:32 UTC
Re: Repository access woes
Marcus Comstedt <ma...@mc.pp.se> writes:
> This is a rather serious obstacle on the "replace CVS" roadmap don't
> you agree? One of the main benefits of CVS is that it's so easy to
> setup. All you do is create a repository somewhere, and presto, the
> project can immediately be checked out anywhere on the local network
> through the wonders of NFS. No hassle setting up servers etc. Seems
> it won't be so easy with Subversion...
If you Google around for CVS-on-NFS, you will find a fair number of
horror stories there too. I don't know how many of them are recent,
but it's not as if CVS has always worked fine over NFS.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Ben Collins-Sussman <su...@collab.net>.
Marcus Comstedt <ma...@mc.pp.se> writes:
> > I'm afraid we don't have a plan for solving this before 1.0, though
> > I'd welcome one. We can't suddenly stop using BDB.
>
> I don't have one either, just alerting you to the problem.
We've been aware of this problem for years. It's not really a
problem, at least IMO. Just start using svnserve or apache.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by kf...@collab.net.
Marcus Comstedt <ma...@mc.pp.se> writes:
> > Can you retrieve all old revisions? (The symptoms were that they
> > would corrupt; but again, we never had a reliable reproduction recipe.)
>
> The reproduction recipe for Subversion is simple at least. :-)
> Just try to do anything with a repository over NFS (like, create it
> for instance) and you get this error:
Sorry, I meant for CVS.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Marcus Comstedt <ma...@mc.pp.se>.
kfogel@collab.net writes:
> Can you retrieve all old revisions? (The symptoms were that they
> would corrupt; but again, we never had a reliable reproduction recipe.)
The reproduction recipe for Subversion is simple at least. :-)
Just try to do anything with a repository over NFS (like, create it
for instance) and you get this error:
gedrix <368> svnadmin create foorepos
svn: Berkeley DB error
svn: Berkeley DB error while creating environment for filesystem foorepos/db:
Resource temporarily unavailable
gedrix <369>
> I'm afraid we don't have a plan for solving this before 1.0, though
> I'd welcome one. We can't suddenly stop using BDB.
I don't have one either, just alerting you to the problem. (What
happened to the SQL backend project btw? Not that a SQL server is
less hassle to set up than svnserver, just curious...)
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by kf...@collab.net.
Marcus Comstedt <ma...@mc.pp.se> writes:
> Well, I have personal experience with CVS working just fine over NFS
> on Solaris systems for something like 7 years. Unfortunately,
> personal experience now also includes Svn bombing out at the very
> first attempt. :-/
Can you retrieve all old revisions? (The symptoms were that they
would corrupt; but again, we never had a reliable reproduction recipe.)
> Blaming the NFS implementation is fine in theory, but it doesn't
> really help making Subversion a "compelling replacement for CVS"...
I'm afraid we don't have a plan for solving this before 1.0, though
I'd welcome one. We can't suddenly stop using BDB.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by kf...@collab.net.
Marcus Comstedt <ma...@mc.pp.se> writes:
> No, but there's bound to be others. In fact, I did the search Karl
> suggested to find all this information about people having trouble
> with CVS over NFS, and all I got was messages saying how functional it
> was and how they were doing it all the time. So I refuse to believe
> it's just me it works for.
Well, sorry, I don't know where they are, but it was definitely a
problem in the mid-1990's. Perhaps it's not anymore...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Jens-Uwe Mager <ju...@anubis.han.de>.
On Tue, Aug 19, 2003 at 03:24 +0200, Marcus Comstedt wrote:
> No, but there's bound to be others. In fact, I did the search Karl
> suggested to find all this information about people having trouble
> with CVS over NFS, and all I got was messages saying how functional it
> was and how they were doing it all the time. So I refuse to believe
> it's just me it works for.
I just want to chime in and say that development with CVS with Solaris
workstations and AIX NFS servers works really fine. All file access is
via NFS, even work spaces. Developers are not allowed to keep files
locally with the exception of test data (in one commercial setup I have
been responsible for). Trying that with Linux was another story.
--
Jens-Uwe Mager <pgp-mailto:F476EBC2>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Marcus Comstedt <ma...@mc.pp.se>.
John Peacock <jp...@rowman.com> writes:
> However, BerkeleyDB does not support /any/ NFS filesystem for the
> database. And it would be silly for Subversion to try and support the
> very small subset of all NFS filesystems that BDB /might/ work on with
> handholding, since everywhere else that support would be useless.
Given the goals of Subverion, being able to do something that CVS can
do is not silly. It may be _hard_, even prohibitly so, but not
silly.
> The fact that _you_ have had no problems with CVS on an NFS partition
> doesn't count for much.
No, but there's bound to be others. In fact, I did the search Karl
suggested to find all this information about people having trouble
with CVS over NFS, and all I got was messages saying how functional it
was and how they were doing it all the time. So I refuse to believe
it's just me it works for.
> (low concurrency CVS repository?).
Nope.
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Jack Repenning <jr...@collab.net>.
At 9:32 PM -0400 8/18/03, Greg Hudson wrote:
>On Mon, 2003-08-18 at 21:24, Paul Smith wrote:
> > using a CVS server to access the repository, but that the repository
> > lives on an NFS-mounted partition rather than on the server's local
> > disk.
>
> > everyone runs CVS operations directly on the repository rather than
>> through a server
>
>These two modes of operation work in basically the same way under CVS;
>if one fails, the other is likely to as well.
Really? I think it's the same code (the "cvs server" is the same
program as the "cvs client"). But in the former case, the many
copies of this program are running on the same host; in the latter,
they are running on distinct hosts. This means, I had understood,
that synchronization (via lock files, since this is CVS) can fail in
the latter case due to network timing / race conditions and NFS
implementation bugs (and misconfigurations)--failure modes that don't
arise in the first case, because they're all sharing the same mount
point and caches.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Marcus Comstedt <ma...@mc.pp.se>.
Greg Hudson <gh...@MIT.EDU> writes:
> (Seems a little odd to put the repository on an NFS server and then only
> access it from one client, but I can imagine reasons to do that, such as
> wanting to have a single backup system.)
There's that, but often¹ it is also the case that the NFS servers don't
allow user processes, and the clients have no user writable local
filesystem (apart from /tmp, where you're unlikely to want to put a
repository :). Then even if you set up a server process, it has to
access the data through NFS.
¹ at least in large systems, with more than 50 clients or so.
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2003-08-18 at 21:44, Ben Collins-Sussman wrote:
> Yes, perhaps subversion raises the barrier-to-entry for setting up a
> shared repository. But in return, you get real database features,
> like transactions, atomic commits, and rollback. That's the tradeoff.
> That's "better" than CVS.
Well, I think we can get the same nice features without using Berkeley
DB, though it would be interesting to see if my ideas are a net
performance win or lose. Regardless, that's definitely post-1.0.
Jack Repenning wrote:
> In the former case, the many copies of this program are running on
> the same host
Yes, good point. That raises the question of whether NFS flaws tend to
manifest only when different client machines are accessing the
filesystem. I don't know enough about NFS implementations to be sure
one way or the other.
(Seems a little odd to put the repository on an NFS server and then only
access it from one client, but I can imagine reasons to do that, such as
wanting to have a single backup system.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Bruce Elrick <br...@entropyreduction.ca>.
Paul Smith wrote:
> %% Ben Collins-Sussman <su...@collab.net> writes:
>
> bc> Greg Hudson <gh...@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.
>
Although NetApp is doing it's best to make it happen, I think the
proportion of RDBMS instances running with their physical files accessed
via the NFS protocol is vanishingly small. In the corporate world I see
you are more likely to see storage servers share out via a block device
protocol like Fibre Channel (or, for IP based nets, iSCSI) with each
server laying down its own filesystem.
How many instances of Oracle or DB2 run over NFS? How many instances of
SQL Server run over CIFS?
But my world is typically business OLTP systems (ERP).
Cheers...
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Paul Smith <pa...@nortelnetworks.com>.
%% Ben Collins-Sussman <su...@collab.net> writes:
bc> Greg Hudson <gh...@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 <ps...@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
Re: Repository access woes
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Hudson <gh...@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.
<rant>
I have to admit, I really don't care whether BerkeleyDB runs over NFS
or not. A BerkeleyDB environment is a far cry from a bunch of RCS
files with locks. It's a *database*. That means you should be using
a server, period. The fact that file:/// urls work at all is mainly
(1) an API sanity check, and (2) allows an individual user to keep a
private repository, when s/he may not have anything but a non-root
shell account.
But when you're talking about setting up multiple users to share a
database -- you've got to treat it seriously. There is no "just
create a repository and everyone pile on!" You set up a real server
process, with real authn/authz.
</rant>
Yes, perhaps subversion raises the barrier-to-entry for setting up a
shared repository. But in return, you get real database features,
like transactions, atomic commits, and rollback. That's the tradeoff.
That's "better" than CVS.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Colin Watson <cj...@flatline.org.uk>.
On Tue, Aug 19, 2003 at 10:21:41AM -0400, Paul Smith wrote:
> %% Greg Hudson <gh...@MIT.EDU> writes:
> gh> Please avoid sweeping generalizations like that one; a great deal
> gh> of large-scale use of CVS does not involve NFS in any way.
>
> You're right: "any" was far too strong; I apologize. However, I'm
> familiar with a lot of larger companies and as a rule they are moving
> away from local disk and towards NAS-style solutions. The latter is
> much simpler to back up, generally more reliable, and less expensive.
> It's not that unusual for companies to require that all critical data
> live on NAS.
Could you get away with simply hot-backup.py-ing the repository onto
NAS? I'm sure it would be possible to argue that the live BDB repository
itself is transient, and that the dump is the actual critical data;
after all, you might not be able to back up a running database without
shutting it down anyway, so this would actually be easier from the point
of view of the company's IT infrastructure.
--
Colin Watson [cjwatson@flatline.org.uk]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by John Peacock <jp...@rowman.com>.
Paul Smith wrote:
> This used to be an issue, but many databases these days are certified to
> work with modern NAS solutions (NetApp and EMC stuff for example). I
> thought even Oracle allowed this, although I'm not sure about that.
You are correct it seems:
http://otn.oracle.com/deploy/availability/htdocs/vendors_nfs.html
However, Sleepycat does not, in general, support remote file systems:
http://www.sleepycat.com/docs/ref/env/remote.html
And the larger point, lest that be lost here, is that Subversion's first target
should be the widest possible environment, not just those few [expensive] NAS
platforms which break the rule.
Hence, until 1.0 is out and other database backends are brought into the fold,
there is basically no point in complaining that Subversion won't run on NFS
partitions. It just doesn't; it is a limitation of BDB that cannot be easily
worked around. If that means that certain enterprises with rules about such
data having to reside on specific filesystems cannot adopt Subversion, that is
the unfortunate reality.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Paul Smith <pa...@nortelnetworks.com>.
%% John Peacock <jp...@rowman.com> writes:
jp> Except for databases, that is, which is what we are talking about.
Nope, not except for databases.
jp> Oracle is similar to BerkeleyDB in that the database has to be on
jp> a local drive to the server (though I think you can put the log
jp> files on a network share). I don't even think under NTFS will
jp> Oracle run on a networked drive (for sure the tablespace creation
jp> dialogue only lists local drives).
This used to be an issue, but many databases these days are certified to
work with modern NAS solutions (NetApp and EMC stuff for example). I
thought even Oracle allowed this, although I'm not sure about that.
To bring it a little closer to home and talk about SCM tools (and things
I _do_ know about :)), ClearCase also uses a database (Raima, heavily
hacked...) in its back-end, but it will properly work with NFS-mounted
storage from both NetApp and EMC fileservers (and maybe others). This
is a valid configuration supported by Rational.
--
-------------------------------------------------------------------------------
Paul D. Smith <ps...@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
Re: Repository access woes
Posted by John Peacock <jp...@rowman.com>.
Paul Smith wrote:
> I don't think this true: with a server implementation only one single
> host is accessing the repository regardless of how many different
> clients are running CVS operations. This is inherently safer than lots
> of different hosts accessing the repository directly.
As I understand it from discussions on the CVSNT list, the actual code used by
the server process to access the RCS is _exactly_ the same code as used by the
CVS client under local mode. The difference (as I understand it) from the NFS
side, is that some NFS implementations have the locking per client, so clientA's
locks won't necessarily block locks from ClientB. If there is only one client
process (i.e. the CVS server), then the locks will work fine (modulo bad NFS
implementations).
> You're right: "any" was far too strong; I apologize. However, I'm
> familiar with a lot of larger companies and as a rule they are moving
> away from local disk and towards NAS-style solutions. The latter is
> much simpler to back up, generally more reliable, and less expensive.
> It's not that unusual for companies to require that all critical data
> live on NAS.
Except for databases, that is, which is what we are talking about. Oracle is
similar to BerkeleyDB in that the database has to be on a local drive to the
server (though I think you can put the log files on a network share). I don't
even think under NTFS will Oracle run on a networked drive (for sure the
tablespace creation dialogue only lists local drives).
I will be testing mounting NAS volumes over iSCSI; it would be interesting if
Berkeley would work fine in that scenario, since the drives are "local" for most
purposes.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Paul Smith <pa...@nortelnetworks.com>.
%% Greg Hudson <gh...@MIT.EDU> writes:
>> If Marcus was talking about a CVS repository shared via NFS where
>> everyone runs CVS operations directly on the repository rather than
>> through a server
gh> These two modes of operation work in basically the same way under
gh> CVS; if one fails, the other is likely to as well. The CVS server
gh> accesses the repository in the same way a CVS process accesses it
gh> directly. (As best I understand CVS, anyway.)
I don't think this true: with a server implementation only one single
host is accessing the repository regardless of how many different
clients are running CVS operations. This is inherently safer than lots
of different hosts accessing the repository directly.
>> likely an issue for any large-scale SVN use.
gh> Please avoid sweeping generalizations like that one; a great deal
gh> of large-scale use of CVS does not involve NFS in any way.
You're right: "any" was far too strong; I apologize. However, I'm
familiar with a lot of larger companies and as a rule they are moving
away from local disk and towards NAS-style solutions. The latter is
much simpler to back up, generally more reliable, and less expensive.
It's not that unusual for companies to require that all critical data
live on NAS.
--
-------------------------------------------------------------------------------
Paul D. Smith <ps...@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
Re: Repository access woes
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2003-08-18 at 21:24, Paul Smith wrote:
> When Marcus talks about CVS via NFS I assumed he meant that people were
> using a CVS server to access the repository, but that the repository
> lives on an NFS-mounted partition rather than on the server's local
> disk.
> If Marcus was talking about a CVS repository shared via NFS where
> everyone runs CVS operations directly on the repository rather than
> through a server
These two modes of operation work in basically the same way under CVS;
if one fails, the other is likely to as well. The CVS server accesses
the repository in the same way a CVS process accesses it directly. (As
best I understand CVS, anyway.)
> likely an issue for any large-scale SVN use.
Please avoid sweeping generalizations like that one; a great deal of
large-scale use of CVS does not involve NFS in any way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Paul Smith <pa...@nortelnetworks.com>.
%% John Peacock <jp...@rowman.com> writes:
jp> The fact that _you_ have had no problems with CVS on an NFS
jp> partition doesn't count for much. You may have been lucky so far
jp> (low concurrency CVS repository?). The strong recomendation has
jp> always been (AFAIK) to not mix CVS and NFS, no matter what O/S you
jp> are talking about.
Hm. I wonder if there's been a misunderstanding.
When Marcus talks about CVS via NFS I assumed he meant that people were
using a CVS server to access the repository, but that the repository
lives on an NFS-mounted partition rather than on the server's local
disk.
If true, then this is of course a common, supported environment that
will work, and if SVN doesn't support this (esp. with the larger
repository sizes it apparently generates) then this is likely an issue
for any large-scale SVN use.
If Marcus was talking about a CVS repository shared via NFS where
everyone runs CVS operations directly on the repository rather than
through a server, then John is quite correct: that is a known bad
configuration and you won't find any CVS expert-types (at least I never
heard of any) who would say that was a reliable configuration. It may
work "most of the time" by chance, but ...
So, I guess we need to define the environment more completely.
--
-------------------------------------------------------------------------------
Paul D. Smith <ps...@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
Re: Repository access woes
Posted by John Peacock <jp...@rowman.com>.
Marcus Comstedt wrote:
> Blaming the NFS implementation is fine in theory, but it doesn't
> really help making Subversion a "compelling replacement for CVS"...
Whether or not _your_ O/S has NFS which will support locking for some operations
is besides the point. The NetAPP people hired at least some of the Solaris NFS
development team for their NFS implementation, and hence they claim at least a
robust NFS implementation as Solaris has.
However, BerkeleyDB does not support /any/ NFS filesystem for the database. And
it would be silly for Subversion to try and support the very small subset of all
NFS filesystems that BDB /might/ work on with handholding, since everywhere else
that support would be useless.
The fact that _you_ have had no problems with CVS on an NFS partition doesn't
count for much. You may have been lucky so far (low concurrency CVS
repository?). The strong recomendation has always been (AFAIK) to not mix CVS
and NFS, no matter what O/S you are talking about.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository access woes
Posted by Marcus Comstedt <ma...@mc.pp.se>.
kfogel@collab.net writes:
> If you Google around for CVS-on-NFS, you will find a fair number of
> horror stories there too. I don't know how many of them are recent,
> but it's not as if CVS has always worked fine over NFS.
Well, I have personal experience with CVS working just fine over NFS
on Solaris systems for something like 7 years. Unfortunately,
personal experience now also includes Svn bombing out at the very
first attempt. :-/
Blaming the NFS implementation is fine in theory, but it doesn't
really help making Subversion a "compelling replacement for CVS"...
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org