Hi Derek,
With this I imported two test modules using MacCVSClient, zlib data stream compression level 3. I use a MacCVSClient beta because the current 1.9 cannot cope with truncated paths in server responses.
I didn't put any checks in the server for whether clients could handle the truncated paths because it was already in the client/server protocol spec, but I could have. I think MacCVSClient isn't the only client that had problems with it, though.
Is it going to cause any trouble for you if I go back in add a NULL client response to the protocol that tells the server that a client can handle the truncated specs?
That would be no trouble at all. I understand what you are saying is this: you'll add a client request (I guess that's what you mean and not a response, or am I wrong here?) to the protocol that the client uses to tell the server it can handle truncated paths. If the client doesn't send this request, the server will behave as it does up until 1.11.x. Am I right?
For smoothest possible transition of users, your suggestion above seems a very good idea. In case you should decide to do this, it certainly would be way cool, if the protocol overview doc did reflect the change... ;-))
I have added automatic truncated path support in MacCVSClient betas a good while ago (as of 20 Nov 2004) and would just wrap a new public release (1.9.1 or so) to support CVS server 1.12 compatibility otherwise. This would still cause a number of users to experience failures and at least temporary incompatibility, though.
Cheers, Joerg
_______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
