Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
From: Andrew Schulman <andrex AT alumni DOT utexas DOT net>
Subject: Re: problems with overloading of the semantics of version number in cygwin/unison
Date: Thu, 6 Jan 2005 14:03:15 -0500
Lines: 52
Message-ID: <MPG.1c47557b7bb75d6d9896ab@localhost>
References: <41DD5107 DOT 8060002 AT reservoir DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
User-Agent: MicroPlanet-Gravity/2.70.2067

Hi Richard.  I'm the maintainer of Unison for Cygwin.

> 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.

You're right that Unison versions 2.9.1 and 2.9.20 won't talk to each 
other.  Nor will either of them talk to 2.10.2, IIRC.  Some of this may 
be just sloppy version checking, I'm not sure.  At least some of 
it is required, because the Unison archive format has changed once or 
twice.  If you tried to synchronize files using versions of Unison with 
incompatible archive formats, then bad things would happen, or so I'm 
told.  That's the reason that the Cygwin developers put in the version 
checking.

> 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

Other people have raised this problem before.  I've been aware of it, 
but haven't managed to tackle it yet.

Your proposed solution is right.  Wherever the archive formats are 
incompatible, there should be a separate package.  For example, instead 
of installing the latest Unison (e.g. 2.10.2-3, which may be 
incompatible with their server's version), the user could install 
whatever version of unison2.9.1, unison2.9.20, or unison2.10.2.

The only reason this hasn't happened yet is because I haven't made it 
happen.  I need to first find out for sure which versions have 
incompatible archive formats, or maybe just which versions will refuse 
to talk to each other.  Then I'll have to redo all of my packaging work, 
say, 3 times over.  Not impossible, but not enticing either.  However, 
since only version 2.9.1 is available to you, I'll move it up in my 
queue and get to it ASAP.

BTW, there have been a lot of new features and bug fixes since version 
2.9.1.  2.10.2 is pretty stable; I think the developers are considering 
making a new stable release soon.  If you can, consider asking your 
server admin to upgrade.

Andrew.


--
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/