info-cvs
[Top][All Lists]
Advanced

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

Re: Issues with network file systems and CVS


From: Mark D. Baushke
Subject: Re: Issues with network file systems and CVS
Date: Tue, 17 Sep 2002 12:56:36 -0700

On Tue, 17 Sep 2002 11:57:30 -0700, Matthew Navarre
<address@hidden> asked:

> We've been using CVS with the repository exported via NFS to our UNIX boxen. 
> now we need to connect to another cvs repo at a remote site and the only 
> access the want to give us is via wincvs with the repository on a mapped 
> drive.
> 
> Now, just from discussion on this list I realise this is bad. My
> question is what are the potential issues with this approach? I need a
> better answer than "I've heard it's bad" to try and cut through the
> fog of developer inertia and blinding stupidity we've got here, not
> that It'll help.
> 
> Could someone explain to me the issues with mounting the repo via a
> network filesystem?

The format of the rcs ,v file does not include any kind of a checksum,
so any corruptions that occur across a network filesystem are not
detected.

Corruptions in the past that I have persionally witnessed include:

    -> automagic insertion of carriage-return characters before
       every newline (eg, writing in text rather than binary mode)

    -> replacing a block with NUL bytes rather than the delta
       information or text file information. In the case of the
       corruption of the delta information, this meant that past
       versions of the file were not available and this was not detected
       for a long time. 

       In another intance, it was later found that a CLIENT machine
       didn't have UDP checksums enabled and that there was a lot of
       network in that part of the network. This caused corrupted
       NFS packets to be used when writing the ,v file.

       This particular problem does not happen when cvs is used remotely
       as cvs takes care to make sure the packet is intact and correct
       on both sides of the connection.

    -> various udp packets being lost to properly create or delete the
       #cvs.rfl or #cvs.wfl lock files for the directory caused some
       stale lock files to be created in some cases and some multiple
       write operations to occur in the same directory at the same time

It is also the case that going to a central server to do the update of
your cvs files allows a process local to the cvs server to determine
that the network connection to its parent on the remote machine has
disappeared so that it can properly remove the cvs locks it has created.

For the above reasons, I strongly recommend that you do NOT use NFS to
update your repository.

I do not have any personal experience with using samba as the remote
filesystem, but the remote CVS capability is easy to use and very
reliable.

I hope the information is of use to you.

        Enjoy!
        -- Mark




reply via email to

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