Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com To: cygwin AT cygwin DOT com From: Andrew Schulman Subject: Re: problems with overloading of the semantics of version number in cygwin/unison Date: Thu, 6 Jan 2005 14:22:58 -0500 Lines: 63 Message-ID: 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> <012a01c4f422$7b537930$5308a8c0 AT robinson DOT cam DOT ac DOT uk> <41DD8D46 DOT 5010602 AT reservoir DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Complaints-To: usenet AT sea DOT gmane DOT org X-Gmane-NNTP-Posting-Host: pcp04396353pcs.nrockv01.md.comcast.net User-Agent: MicroPlanet-Gravity/2.70.2067 X-IsSubscribed: yes > Max Bowsher wrote: > > > 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. > > Where does the version number 2.9.20-1 come from? Internally, Unison's version number is 2.9.20. In the Cygwin distribution, that package is numbered 2.9.20-1 because it's the first release of Unison 2.9.20 in Cygwin. If I were to apply some bug fixes or other changes and release a new version of 2.9.20, it would show up in the Cygwin mirrors as 2.9.20-2. But Unison would still tell you that you were using version 2.9.20. HTH, A. -- 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/