Re: cvs [log aborted]: linefeed expected in file.c,v

[Laine Stump]

Rob Helmer <address@hidden> writes:

> Just so I understand the problem, is it ok to mount a sandbox
> over NFS or samba, work on it, ssh to the sandbox ( let's
> say it's a home directory ) and do cvs commit there?

As Dereck confirms, the main problem with CVS and remote filesystems
is when the CVS repository itself is mounted from a remote location to
a local disk. A remote work directory isn't nearly as dangerous, and
(as you say) is quite useful.

There is one potential problem though - if you have a work directory
on a Unix box and you do some modifications (eg cvs operations,
editing files) on the Unix box, and some on a Windows box (eg
compiling, more editing), you'll find that the Unix and Windows
machines sometimes don't agree on the contents of the files.

This is because Samba implements "oppurtunistic" locks on files -
locks which a client can create, and which are then broken by the
server when someone else modifies the file in the area that was
locked. The problem is that the Samba server, being a userland daemon,
can properly (and efficiently) recognize and notify when another Samba
client does something that necessitates breaking a lock, but it
*can't* recognize when something other than Samba (eg, another NFS
client, or an Emacs running locally on the Unix box) necessitates
breaking the lock; the result is that teh client machine thinks that
its cached data is valid when it isn't.

Irix has implemented kernel hooks to allow the filesystem to directly
notify Samba when a lock must be broken, but no other OS has done it
yet. In the meantime, you need to be careful about this, or set the
registry as described in:

    docs/textdocs/File-Cacheing.txt

in the Samba source distribution (which also contains a much better
description of the problem).

Having said that, I have been using cvs + samba + windows + unix in
exactly this way for several years now, and have never suffered any
terrible tragedy. As long as you know the conditions you're working
under, the problems can be worked around.

(P.S. - another potential problem is that is you use CVS on the Unix
box, all the files will be checked out with just LF at the end of each
line. Some Windows utilities handle this just fine (eg, the MSVC++
compiler), but others don't (eg, notepad, and the editor in MS Visual
Studio). I just do most all of my editing with Emacs on an X display
from the Unix box. Someone recently pointed me to a Visual Studio
AddIn that removes CRs from all files as Visual Studio saves
them. It's at:

   http://codeguru.earthweb.com/devstudio_macros/stripem.shtml