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.
Thomas Singer wrote: > It worked in CVSNT 2.0.58d and still works in any half-decent GNU CVS > version, so I guess it is a newly introduced incompatibility in CVSNT > 2.5.*. It shouldn't, since the purpose of -k on import is to force all the files to be the same (usually binary when I've seen it used, although that's rare). Unfortunately GNU cvs doesn't support any kind of modification of expansions so you can't for example apply -ko globally on checkout without corrupting all your binary files.. that's just a limitation of the older server. CVSNT disambiguates the whole thing defining absolute and relative expansion options. Global -k options should in most cases be relative... you don't know what options the server wants to add on the file and overriding it blindly will mean that things get lost. > Does this also works for files without a period? Just * will work, but most windows users think in terms of *.*.. they're functionally equivalent. > I doubt, that this is the best (BTW, "bin" was just a sample extension, > it also could have been "foo", "bar" or "bazz"). SmartCVS (like WinCVS?) > scans the files for "mysterious" characters and then suggests, whether > it is a binary or text files, but the user of course can change it > manually. It's a bad idea - you'll override the global options for the files you're importing - for example the server may have been set to use -kbx or -kB instead of -kb and a client overriding this on import will create problems (eclipse is the worst at this, forcing -kkv on everything it doesn't know about... working around this is still not complete and will probably require some kind of annoying hack). Unless explicitly overriden by the user the server defaults should be used. Tony