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.
Paul Balmforth wrote: > For a number of years, I've been working for a MNC and > developing/maintaining a CVS client for our product. We strive to > ensure that it's compatible with the latest CVSNT server in addition > to builds of Cyclic CVS. We certify against CVSNT and recommend it to > our customers. More often than not minor differences and > incompatabilities have been easily addressed, until now. > > It seems the CVSNT server no longer defaults the 'kopt' of an > imported file to the wrapper definitions, instead relying on the > client to pass the correct value in a 'Kopt' request. This is bad > news because: That functionality hasn't changed at all. The server *must* believe the client version of Kopt because it's the only way to know what the file was checked out as. > - it places a responsibility on the client to parse and evaluate the > wildcards described in cvswrappers (or wrapper options). The new No it doesn't - no client does that - in fact we recommend disabling the ability of clients to override the wrappers on the server since clients often have different ideas of what is binary. > CVSNT server expects a non-standard argument to the 'Kopt' request. > Specifically, when the file is binary, it expects "Kopt b" and not > "Kopt -kb". It accepts either. > This means, if I make my client operate as the CVSNT server expects, > then use the client it with a Cyclic CVS server, I'm seeing this > exception: I strongly suggest you call the standard CVS binary to avoid such incompatiblities. The protocol has not changed. Tony