Hi Steve, There are many cases where NFS clients have opened a file on an NFS server and written to it and the text written to disk is not the same as the text the client was attempting to write. Par
NFS is discouraged because there have traditionally been problems with subtle incompatibilities between implementations, and it must also be configured properly in order to maximize reliability. Also
Is your CVS repository on an NFS-mounted filesystem? If so, that's almost certainly the root cause of your problem: we've had lots of reports of repository corruption caused by NFS interoperability p
Yes that is the best advice. Whilst Larry's suggestions are good, I would also like to point out that if your repository becomes corrupt that: A) you may not know of the corruption unless you are lo
I'm using a pserver to access the dbase and we're using Solaris 5.8 as our OS with NFS files system. I found a work around for this problem, but have no idea why it ocurred in the first place. The fi
Kenneth, Yes that is the best advice. Whilst Larry's suggestions are good, I would also like to point out that if your repository becomes corrupt that: A) you may not know of the corruption unless yo
Yup, one particular 'NFS' configuration option that has caused problems was that UDP checksums were not enabled by all clients and/or servers that were trying to access the repository. This may allo
Is it just the ADD/COMMIT over an NFS that would cause the corruption, and, presuming an as-of-yet uncorrupted repository, doing a CHECK-OUT over an NFS mounted repository would NOT cause corruption;
Hi , I am looking for a patch/script for branch locking in CVS . I am using CVS 1.10 on RedHat 6.2. I have tried using CVS Admin command for this purpose but it doesnot work. Thanks. Rakesh Rakesh Dh
A 'cvs add' should not be a huge problem as only directory creation may go awry which will be easily discovered when a user goes to add and commit files later. The dangerous operations are 'cvs commi
The correct question is this: "Is it ever acceptable that a 'cvs commit' may corrupt the repository without any notification of any problems whatsoever until much time has passed and there is a need
Good Afternoon,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> I have a few more questions related to performance. Some MAY be a bit 'out-of-the-box, but please bare with
You are trying to share ,v files across multiple repositories using symbolic links and NFS mounts? Be glad it doesn't work! If it did, you would soon corrupt your repositories due to missed locks, no
Oopps :(, actually this problem it happened after I deleted some revisions for this file with "cvs admin -o rev2::rev32 SRMActuateReports.dll" , actually I did this command only for this file, the fi
Thanks Larry: I was checking yesterday the same command for a different file and after that the file is corrupt, I was thinking that this command "cvs admin -orev1::rev2" is only useful for text file
-- Forwarded mail from address@hidden There's a book about applying CVS to configuration management. I don't remember the name, but "CVS" is in the title. I believe Karl Fogel is one of the authors.
I would say that it is likely necessary, but may not be sufficient. I am unclear how this lets you perform a speedup. I am given to understand that many of the anicillary tools that surround CVS make
That, by itself, wouldn't corrupt the RCS file. That implies that the damage is to one of the delta sections. By checking out previous versions (you can use -p and send the output to /dev/null) and s
Arthur Barrett writes [quotin me]: I'm talking about physical device mounts, not NFS mounts. SGID etc. works just fine and there aren't any special security risks to worry about. -- Larry Jones I thi
Have you reported the problems to the Eclipse folks? A separate e-mail on what problems you ran into may be useful to help other folks some day. Well, that might help you scale a bit more I am not aw