This is the mail archive of the
cygwin-talk@cygwin.com
mailing list for the cygwin project.
RE: RFU: unison-2.9.1, unison-2.9.20, unison-2.10.2
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Talk Amongst Yourselves, but only if your version numbers are identical'" <cygwin-talk at cygwin dot com>
- Date: Sun, 6 Mar 2005 10:46:47 -0000
- Subject: RE: RFU: unison-2.9.1, unison-2.9.20, unison-2.10.2
- Reply-to: Talk Amongst Yourselves <cygwin-talk at cygwin dot com>
----Original Message----
>From: Brian Dessent
>Sent: 06 March 2005 08:06
> Andrew Schulman wrote:
>
> [I recall reading these threads when the issue were first brought up.
> However, at that point the notion of having a separate package for each
> version of the program sounded so far fetched...]
>
>> It turns out
>> that by the design of Unison, if you are running, for example, version
>> 2.10.2 and attempt to synchronize with a server running version 2.9.20,
>> Unison will issue an error message about incompatible versions and quit.
>
> Wow... that's just so... wow.
The word "overcautious" springs to mind...
> How could any rational software developer think that such a policy makes
> a lick of sense?
It makes plenty of sense to me, but I've just been repeatedly smashing a
brick over my head and I've got a massive concussion! :)
>> This design
>> choice was apparently made to safeguard against possible changes in both
>> the network protocol and archive formats between versions of Unison.
>
> Could someone airdrop a clue here? Shouldn't it be a trivial
> realization that the wire protocol, archive format, and program version
> could be different things?
I guess just because future versions of the protocol are
backwardly-compatible, they still want the code to be safe against
forwardly-incompatible changes to past versions of the code. What if
someone goes back in a time machine and changes the behaviour of an older
version of the code, after all? This protocol protects against it!
Oooh, but what if the same malicious time-travelling software engineers
also changed the version number string?
Hmm. I suggest this patch:
DKAdmin@ubik /usr/src/unison-2.9.20> cp remote.ml remote.ml.new
DKAdmin@ubik /usr/src/unison-2.9.20> diff -pu remote.ml remote.ml.new
--- remote.ml 2005-03-06 10:42:07.725894400 +0000
+++ remote.ml.new 2005-03-06 10:41:58.923236800 +0000
@@ -1002,8 +1002,12 @@ let rec checkHeader conn prefix buffer p
^ "\" but received \"" ^ String.escaped (prefix ^ buffer) ^
"\".\n"
^ "This is probably because you have different versions of
Unison\n"
^ "installed on the client and server machines.\n"))
- else
- checkHeader conn (prefix ^ buffer) buffer (pos + 1) len)
+ else
+ (* mummy i'm scared *)
+ Lwt.fail
+ (Util.Fatal
+ ("Matching version on client and server.\n"
+ ^ "But what if it's not compatible with itself? Aborting to be
safe.\n"))
(****)
cheers,
DaveK
--
Can't think of a witty .sigline today....