RE: MT response and update -p command

[Milos Kleint]

> 
> Milos Kleint writes:
> > 
> > It actually works fine all the time, except one case. when 
> doing update -p
> > <file> or checkout -p <file>
> > If the file doesn't end with a new-line, then the final 
> line of the source
> > is discarded. While debugging this behaviour and by comparing our
> > client-server communication and the cvs.exe one, I realized 
>  the the final
> > line is sent (as opposed to the rest of the file) with the 
> MT response.
> > And because we don't support it, the server decided to send 
> nothing to us.
> 
> This is historical.  Before CVS had the MT response, that is exactly
> what happened to a final partial output line -- it was discarded.

So the MT response is the fix to the the bug? :)

> 
> > I'm aware of the fact that it "hack" is used to set the 
> right new-lining to
> > the file being sent however IMHO it should at least send the wrong M
> > response.
> 
> I'm inclined to agree -- anyone want to argue against such a change?
> 
> > Is this really a bug or do we have to support the MT 
> response? Where to fill
> > this bug? Is there any list of required responses and 
> requests? I couldn't
> > find anything like that in the Cvs client/server document.. 
> Is there a more
> > in-depth description of the MT response somewhere?
> 
> The MT response is the only way the protocol has to support a partial
> line; if you want your clients to support partial lines, then you'll
> have to support MT.  It's described in detail in 5.11 and 5.12 of the
> CVS Client/Server document; required commands and responses are
> discussed in 5.14.  Bug reports (as per HACKING) go to 
> address@hidden
> 

Well, the 5.14 chapter says no word about MT being required. That's why we
decided not to implement, because we didn't find the 5.12 chapter quite
clear and detailed and we thought that we can start with only M and E
responses and that we can add MT later. 
So if MT is actually required, that should be added to the document.

Milos Kleint