[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

testing different versions of client/server against each other

From: Stephen Cameron
Subject: testing different versions of client/server against each other
Date: Thu, 14 Jun 2001 14:51:06 -0700 (PDT)

Tinkering around with my ".trunk + .origin" patch, I realized if it were ever
to make it into mainstream CVS, there will inevitably be interaction between
unpatched clients and patched servers and also between patched clients and
unpatched servers.

One would hope that they would behave reasonably well together, but right now
the patch takes no special actions to determine if the other side of the
connection is patched or unpatched.  I think there might be some things that
neither work nicely nor fail to work nicely if you attempt to use the new
features and only one of the client/server pair is patched to handle it.  (e.g.
if you have an unpatched client, you can still get away with "cvs co -r .trunk
modulename", and various other things appear to work anyway)  I don't know that
_everything_ works right though.  I was looking at to see if there
was a way I could specify a different CVS for the server vs. the client. 
There's a CVS_SERVER variable, but in the TODO list at the end, it seems this
is to be removed, and may have been partially removed already.

So, two questions 1) Is there any easy way to get to test different
versions of client and server against each other? (more to characterize the
breakage than anything else) and 2) would it be a good idea for client and
server to give each other some idea of what they can and cannot tolerate?  For
this latter, I suppose the simpler the better, maybe exchange version numbers
and compare against a list of konwn-to-work-with (or maybe,
known-not-to-work-with)  and proceed or not based on that?

How has this kind of thing been handled before? Or maybe it never came up? 

-- steve

(the patch I refer to is here: )

Do You Yahoo!?
Spot the hottest trends in music, movies, and more.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]