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 Message-ID: <41DD8D46.5010602@reservoir.com> Date: Thu, 06 Jan 2005 14:11:02 -0500 From: Richard Lethin Organization: Reservoir Labs, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: Max Bowsher CC: cygwin AT cygwin DOT com, unison-users AT groups1 DOT vip DOT scd DOT yahoo DOT com Subject: Re: problems with overloading of the semantics of version number in cygwin/unison 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> In-Reply-To: <012a01c4f422$7b537930$5308a8c0@robinson.cam.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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? > > Cygwin unison works without problems with other copies of cygwin unison, and this is only marginally useful. > and any other platform's unison of the same version. Right, but who else uses the version number of 2.9.20-1? > > Max. > -- Richard Lethin Reservoir Labs, Inc. +1-212-780-0527 ext. 102 www.reservoir.com -- 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/