Hi Mike, Greg. I'm not sure whether this is the problem Greg was asking about, but it appears to be related to a headache I'm having. In my case, Win98 and Linux sharing the same working copy on the same local file system. This is NOT a case of networked file systems, but of dual-boot systems that are sometimes booted into Win98 and sometimes into Linux, with the CVS working copy on a VFAT partition.
>> This bug exists on all platforms, but only exhibits itself when two >> platforms with different line endings are sharing the same working >> copy of the source. In that situation (say Linux and NT), the NT >> will leave ^M characters in CVS/Repository, CVS/Entries, CVS/Root.. >> possibly other places. The UNIX machine will then choke on those >> ^M's, or be unable to find the repository or version based on those >> line endings. > The normal answer is: Simply do NOT do this. > The general consensus is, you should NEVER use cvs over a network > based file system (NFS, SMB, NCPFS, and so on). Where in the above does it say "network-based file system" ??? I for one can imagine precicely this happenning on a dual-boot system with CVS installed on both Linux and Win98 (a combination that exists on several systems I admin) > The reason for this is that there is a history of incompatibilities > between client and server implementations, on all fronts, that CVS > can often trip over. Perhaps you can summarise the ones that apply to a dual-boot environment, where a user is developing both the Win9x and Linux versions of a particular module on the same machine? > Not to mention significant performance hits that revolve around > reading/writing the entire ,v files over a network vs. a server > handling them locally. How does this relate to a dual boot environment? > And not to mention that CVS is designed to access files in native > format, as you've noticed. _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
