Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On 9/3/06, Tony Hoyle <tony.hoyle at march-hare.com> wrote: > Yongwei Wu wrote: > > Since one cannot predict in advance all the consequences, I would > > prefer to make all text files have UNIX line endings under the Cygwin > > environment. > > Then run cygwin CVS (and make sure you never run a win32 tool over the > sandbox *ever* because it'll corrupt the remote repository and you won't > be a very popular person). So you are encouraging me not to use CVSNT? For the record, I maintain cvsmenu.vim. I tested a few minutes ago and can tell you that it must have UNIX line endings to work under Cygwin. I mostly use gVim (native Win32 build) to edit it and test it (NOT in the Cygwin environment). It is easier to copy the file around (or, better, use a soft link to point to the copy in native version of Vim to avoid versioning problems), instead of running scripts like dos2unix. > > I am afraid even you, the author, cannot anticipate nor prescribe all > > possible usages of the tool you brought about. > > There are choices made. --lf is an easy one. It has never been > documented as existing in the first place, doesn't work properly, and > breaks repositories. I have stated previously in this thread that this options does not `break' repositories. It can have bad effects if you do not understand what it is. No one can prevent you from shooting in your own feet. Luckily it is possible to take this bullet out and restore the repository to the old state. And without this option people can make this kind of mistakes too: say, I commit a DOS text file under Cygwin. It has *exactly* the same effect. SO THE `DANGER' IS STILL THERE IF I USE CYGWIN CVS. Maybe it is there if I use CVSNT in Linux--but I have never tested this configuration. The purpose of --lf, I believe, is to emulate a UNIX environment in Windows: nothing more, nothing less. Every mistake you can make with it can happen under *NIX too. > If 2.5 wasn't in code freeze I'd remove the option right now to finish > the argument once and for all. It makes no difference to me: removing it or making it unusable. In either case I have to revert to an old version, and stay away from it. > > Currently SVN has a big momentum in converting existing CVS users. > > The big advantage of CVSNT is that it is supposed to be compatible > > with CVS. At least it is the reason I choose to use CVSNT--all > > existing > > --lf has nothing to do with CVS compatibility. It exists in versions of > CVSNT for compatibility with a WinCVS option and for no other reason. It is still a compatibility issue (with WinCVS and TortoiseCVS, which I used to use; now I prefer the command lines more). Yes, I began to use this option when I first used WinCVS. It is clear an option exists because there is a reason. > The CVS standard is to checkout text files as proper text files for the > platform it's run on, as documented in the manual. This has always been > true, and I suspect is true of all version control systems. For cross-platform usage, people sometimes need UNIX line endings on Windows. Cygwin, UWIN, and MSYS (MinGW build environment) are examples. If you insist you do not want CVSNT to be used in those environments ... > To be 100% compatible with CVS you're basically saying I should remove > --lf immediately because its use is not 'compatible'. I'm tempted to do > that. Having an extra option does not break compatibility. Removing an option does (like in this case, and what you did with `commit -r'). Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/