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/4/06, Flávio Etrusco <flavio.etrusco at gmail.com> wrote: > > Yongwei Wu wrote: > > May I intromit again? ;-) Of course :-). Thanks for mentioning the need of `-f' in commit to make k+L persistent. > First I'd like to assure I understand your problem correctly. It's > that 'update -lf' was sticky but 'update -k+L' isn't (as any 'update > -k' option), right? Quite the contrary. --lf is not sticky, and you need to specify it each time on the command line. -k+L is either too unsticky (lost after a commit), or too sticky (make itself to the server and affect other users). The other major difference is that --lf is a pure client-side option: it does not affect the repository (well, unless you are doing foolish things). -kL is an expansion mode and can propagate to the server. And it does not work with a CVS server. > 1) Isn't 'checkout -k+L' supposed to maintain "stickiness"? I would love the possibility to keep my local files always in LF line endings. > 2) Is everyone else in your projects working differently than you? Well, for CVS repositories, -kL has not effect, and it is all my personal needs to keep the files in UNIX line endings. For CVSNT repositories, I really do not use --lf in real worlds. (It happens to be the case that the source trees I want UNIX line endings are all based on CVS instead of CVSNT.) > 3) I've just checked that svn doesn't seem to offer any kind of > feature like this ;-) Maybe (I do not use SVN currently). But SVN has Cygwin ports, I believe. > 4) It's not part of the UNIX philosophy to provide options that allow > one to easily shoot oneself in the foot ;-) Um, I tend to disagree (and it is easy to shoot oneself under UNIX: someone even calls it an indispensable educational experience). UNIX tools tend to be powerful and allow you to do anything, and will not drop an option just because it *can* be dangerous, because the basic assumption is that the user is smart and know what he/she is doing. And I do not think UNIX tools ever drop options without providing a better alternative. In the current case, there are no alternative options at all if the server is CVS. The most important reason I want CVSNT (instead of CVS) is because it provides a better CVS server on Windows. UTF-16 file support, finer-grid ACL, better merging support, better binary data handling, and rename support are also nice to have. Just for the record. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/