info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Understanding problems with NFS & CVS.


From: Todd Denniston
Subject: Re: Understanding problems with NFS & CVS.
Date: Wed, 05 Sep 2001 10:08:57 -0500

Alex Holst wrote:
> 
> I fear I may have misunderstood the problems with NFS and CVS. As the two
> different threads in the archives on NFS didn't clarify the issue for me, I
> hope someone can clarify.
> 
> I was under the impression that it was bad to share the CVS repository over
> NFS, so hence I have kept our repository on local disks in a machine that is
> accessed via SSH.
> 
> For various reasons, I was queried why the repository is not placed on a NFS
> storage device, mounted on the CVS server which is then accessed via SSH. I
> quoted the NFS sharing problems, but the person retorted saying he has
> experienced large projects using NFS mounted on a frontend machine. Can
> anyone comment on the reliability of this? I don't understand why the
> problems would be any different simply by using a frontend machine. It's
> still NFS with whatever problems it carries with it.
> 
> Thanks,
> Alex
because you are only having one machine do the disk/NFS access, so there are no
race conditions with the creation of locks files (yes I still think there is a
race ... I have seen the problem when all machines were running the same
version and patches of solaris with ~8 developers).  Apparently AFS may be a
bit better at handling the locks, but try looking for threads on AFS as well,
these issues were discussed there and some of my errors in thinking were
corrected by Larry there.  

"Re: CVS and AFS"
"22 Jun 2001"
-- 
______________________________________________________________________________
Todd Denniston, Code 6067, NSWC Crane mailto:address@hidden
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb.  Thank you.
        -- Vance Petree, Virginia Power



reply via email to

[Prev in Thread] Current Thread [Next in Thread]