[Unison-hackers] Re: patches for 2.10.2 and 2.12.0

[Andrew Schulman]

> One thing that is disturbing is that I have to search through the
> mailing list to get the patches that are crucial for the unison
> functionality.  Can somebody put these patches together and make a
> really stable version like 2.9.1 used to be?
> Can you at least put the patches in one place for easy access and a
> comment for which platform are they important?
> 
> If not, then perhaps, Max Bowsher could help me by sending all the
> patches he has applied to his Windows port.  (Thanks Max I use it
> between my office machine and my OpenBSD server.)

I've also been thinking about this problem.  
 
Short term answer:  There should be a way for all of us to coordinate 
our patch sets, so people can synchronize across platforms and expect 
to see the same set of features and bugs.
 
FWIW, here are the patches that I've used to build the current Cygwin 
packages:

http://home.comcast.net/~andrex/cygwin/unison2.10.2/unison2.10.2-patches.zip
http://home.comcast.net/~andrex/cygwin/unison2.12.0/unison2.12.0-patches.zip

I've derived my list of patches just by following the Unison lists.  
Each zip file includes a README that refers to the messages where the 
patches were posted.

Long-term answer:

Versioning and patches in Unison are a problem.  The problem goes back 
to the design decision of the Unison developers, that different 
versions of Unison should be considered incompatible and refuse to talk 
to each other.  As I understand it, this potential incompatibility 
derives from possible differences in either the archive file format, or 
the network protocol, or both.

While I appreciate the problem of potential incompatibilities as Unison 
develops, this system is a mess for packagers and users.  In Cygwin, 
there are now four Unison packages: unison2.9.1, unison2.9.20, 
unison2.10.2, and unison2.12.0.  Each has a separate, correspondingly 
named executable.  I was forced to do this, because Cygwin users 
synchronize with servers running all of these versions, so they need to 
have all of them present on the client side as well.  Every time a new 
beta release is declared, I'll have to create a new Cygwin package for 
it.  And for users, making sure they're using the same version on 
client and server is part of their configuration process.

Unfortunately, declaring a new stable or beta release won't help this 
situation, because users will be forced to continue using their same 
version of Unison until their servers upgrade.  For example, right now 
in Debian there are two Unison packages: unison2.9.1, and unison, the 
latter available in versions 2.9.1 and 2.10.2.  If you're synchronizing 
with a Debian server, you have to either use one of these versions or 
build your own.

So instead what we have is packagers (you, me, Max, ...) applying 
patches as best they can to, say, version 2.10.2.  This results in 
multiple, slightly different versions of 2.10.2, all called "2.10.2" so 
that they'll talk to each other.

In the short term, we should coordinate our patches.  I'm open to 
whatever is the best way to do that.  And, we need the Unison 
developers to help us by making patches available.  For example, the 
recent diff-over-ssh fix was made available as patches to 2.10.2 and 
2.12.0, but the dotfiles-in-iso9660 fix wasn't (at least not yet, as 
far as I've seen).  It was only merged into the development tree.

As a permanent solution to this problem, I wonder if it would be 
possible to introduce archive and network protocol version numbers into 
Unison.  Then, instead of declaring a version mismatch based on the 
Unison version number, Unison could declare a mismatch only if the 
archive or network protocol version numbers were different.  Of course, 
that itself would require a change to the network protocol.  But it 
would be well worth it, IMO.

Andrew.