[cvsnt] file corruption using CVSNT against non-CVSNT client

[Tony Hoyle]

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