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: <41DD5107.8060002@reservoir.com> Date: Thu, 06 Jan 2005 09:53:59 -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: cygwin AT cygwin DOT com Subject: problems with overloading of the semantics of version number in cygwin/unison Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 -- 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/