Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<012a01c4f422$7b537930$5308a8c0@robinson.cam.ac.uk>
From:	"Max Bowsher" <maxb AT ukf DOT net>
To:	"Richard Lethin" <lethin AT reservoir DOT com>
Cc:	<cygwin AT cygwin DOT com>, <unison-users AT groups1 DOT vip DOT scd DOT yahoo DOT com>
References:	<41DD5107 DOT 8060002 AT reservoir DOT com> <004c01c4f403$6d425740$5308a8c0 AT robinson DOT cam DOT ac DOT uk> <41DD5B6D DOT 9080909 AT reservoir DOT com>
Subject:	Re: problems with overloading of the semantics of version number in cygwin/unison
Date:	Thu, 6 Jan 2005 19:01:11 -0000
MIME-Version:	1.0
X-IsSubscribed:	yes

Richard Lethin wrote:
> Max Bowsher wrote:
>
>> Richard Lethin wrote:
>>
>>> There is a problem with the way that cygwin is updating the version
>>> numbers for cygwin/unison.  Unison is used to synchronize filesystems;
>>> it can cross different operating systems over IP.  The protocol uses the
>>> version number to decide whether two processes on different systems will
>>> communicate.  2.9.1 is the official released version.  There is a beta
>>> version 2.10.2, but it is not widely deployed.  Thus people (like me)
>>> will want to use the 2.9.1 version of cygwin's unison.  However, cygwin
>>> is numbering its instance of this version 2.9.20-1.  When you try to
>>> communicate using cygwin's 2.9.20-1 with a standard 2.9.1 version of
>>> unison running on another system, the communication fails after the
>>> handshake when it discovers that the cygwin version is "2.9.2 [sic]".
>>> Yes, I think that the handshake is truncating the protocol string.
>>>
>>> Anyway, my suggestion is that cygwin update the version of 2.9.1 that it
>>> is distributing, to separate the overloaded concept of version number
>>> into a cygwin version number (which could then be arbitrary) and leave
>>> the protocol number at 2.9.1
>>
>>
>> No, this is nothing to do with cygwin, and everything to do with
>> unnecessary inflexibility in the version checking of unison.
>>
>> It would be a very bad thing for Cygwin to distribute a version of
>> unison which lies about which version it is to the other end of the
>> connection.
>
> Sure, it's a bad design choice in unison, but cygwin is using the
> version number in Unison - which means something about the protocol
> version in unison - to mean something about the software release - which
> operationally is not what unison really means.  The result is that
> cygwin unison is broken.

Unison itself uses the same version number for protocol of software release.
That is a problem if you cannot obtain unison binaries for all machines you 
wish to synchronize between from a single source.
Nothing in this problem is in any way cygwin specific.

Cygwin unison works without problems with other copies of cygwin unison, and 
any other platform's unison of the same version.

Max.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -