pool/unison
SHA256
2
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1f6f142cf1
unison/unison-2.17.1-manual.html

3990 lines
214 KiB
HTML
Raw Blame History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.08">
<STYLE type="text/css">
.toc{list-style:none;}
.title{margin:auto;text-align:center}
.center{text-align:center;margin-left:auto;margin-right:auto;}
.flushleft{text-align:left;margin-left:0ex;margin-right:auto;}
.flushright{text-align:right;margin-left:auto;margin-right:0ex;}
DIV TABLE{margin-left:inherit;margin-right:inherit;}
PRE{text-align:left;margin-left:0ex;margin-right:auto;}
BLOCKQUOTE{margin-left:4ex;margin-right:4ex;text-align:left;}
.part{margin:auto;text-align:center}
</STYLE>
<META name="Author" content="Benjamin C. Pierce">
<link rel="stylesheet" href="http://www.cis.upenn.edu/~bcpierce/unison/unison.css">
</HEAD>
<BODY >
<!--HEVEA command line is: hevea unison-manual.tex -->
<!--HTMLHEAD-->
<!--ENDHTML-->
<!--PREFIX <ARG ></ARG>-->
<!--CUT DEF section 1 -->
<BR>
<BR>
<div id="manualbody"><BR>
<BR>
<div id="manualheader"><DIV CLASS="center"><FONT SIZE=7><FONT COLOR=black>Unison File Synchronizer</FONT><BR>
<FONT SIZE=6><FONT COLOR=black>User Manual and Reference Guide</FONT><BR>
<FONT SIZE=5>Version 2.17.1<BR>
</FONT></FONT></FONT></DIV></div><BR>
<BR>
<!--TOC section Contents-->
<H2 CLASS="section">Contents</H2><!--SEC END -->
<BLOCKQUOTE CLASS="quote">
<A HREF="#intro"><FONT SIZE=4><B>Preface</B></FONT></A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#people">People</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#lists">Mailing Lists and Bug Reporting</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#status">Development Status</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#copying">Copying</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#ack">Acknowledgements</A><BR>
<A HREF="#install"><FONT SIZE=4><B>Installation</B></FONT></A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#download">Downloading Unison</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#afterinstall">Running Unison</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#upgrading">Upgrading</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#building">Building Unison from Scratch</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A HREF="#build-unix">Unix</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A HREF="#build-win">Windows</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A HREF="#build-opts">Installation Options</A><BR>
<A HREF="#tutorial"><FONT SIZE=4><B>Tutorial</B></FONT></A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#prelim">Preliminaries</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#local">Local Usage</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#remote">Remote Usage</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#rshmeth">Remote Shell Method</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#socketmeth">Socket Method</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#usingit">Using Unison for All Your Files</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#usingmultiple">Using Unison to Synchronize More Than Two Machines</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#further">Going Further</A><BR>
<A HREF="#basics"><FONT SIZE=4><B>Basic Concepts</B></FONT></A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#roots">Roots</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#paths">Paths</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#updates">What is an Update?</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#conflicts">What is a Conflict?</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#recon">Reconciliation</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#failures">Invariants</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#caveats">Caveats and Shortcomings</A><BR>
<A HREF="#reference"><FONT SIZE=4><B>Reference Guide</B></FONT></A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#running">Running Unison</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#unisondir">The <TT>.unison</TT> Directory</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#archives">Archive Files</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#prefs">Preferences</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#profile">Profiles</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#profileegs">Sample Profiles</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A HREF="#minimalprofile">A Minimal Profile</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A HREF="#basicprofile">A Basic Profile</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A HREF="#powerprofile">A Power-User Profile</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#backups">Keeping Backups</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#merge">Merging Conflicting Versions</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#ui">The User Interface</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#exit">Exit code</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#pathspec">Path specification</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#ignore">Ignoring Paths</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#symlinks">Symbolic Links</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#perms">Permissions</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#crossplatform">Cross-Platform Synchronization</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#speed">Slow Links</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#fastcheck">Fast Update Detection</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#click">Click-starting Unison</A><BR>
<A HREF="#ssh"><FONT SIZE=4><B>Installing Ssh</B></FONT></A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#ssh-unix">Unix</A><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#8226;<A HREF="#ssh-win">Windows</A><BR>
<A HREF="#news"><FONT SIZE=4><B>Changes in Version 2.17.1</B></FONT></A><BR>
</BLOCKQUOTE>
Unison is a file-synchronization tool for Unix and Windows. It allows
two replicas of a collection of files and directories to be stored on
different hosts (or different disks on the same host), modified
separately, and then brought up to date by propagating the changes in
each replica to the other.<BR>
<BR>
Unison
shares a number of features with tools such as configuration
management packages (<A HREF="http://www.cyclic.com/">CVS</A>,
<A HREF="http://www.XCF.Berkeley.EDU/~jmacd/prcs.html">PRCS</A>,
etc.),
distributed filesystems
(<A HREF="http://www.coda.cs.cmu.edu/">Coda</A>,
etc.),
uni-directional mirroring utilities
(<A HREF="http://samba.anu.edu.au/rsync/">rsync</A>,
etc.),
and other synchronizers
(<A HREF="http://www.pumatech.com">Intellisync</A>,
<A HREF="http://www.merl.com/reports/TR99-14/">Reconcile</A>,
etc).
However, there are several points where it differs:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Unison runs on both Windows (95, 98, NT, 2k, and XP) and Unix (OSX, Solaris,
Linux, etc.) systems. Moreover, Unison works <EM>across</EM>
platforms, allowing you to synchronize a Windows laptop with a
Unix server, for example.
<LI CLASS="li-itemize">Unlike a distributed filesystem, Unison is a user-level program:
there is no need to modify the kernel or to have
superuser privileges on either host.
<LI CLASS="li-itemize">Unlike simple mirroring or backup utilities, Unison can deal
with updates to both replicas of a distributed directory structure.
Updates that do not conflict are propagated automatically.
Conflicting updates are detected and displayed.
<LI CLASS="li-itemize">Unison works between any pair of machines connected to the
internet, communicating over either a direct socket link or
tunneling over an encrypted <TT>ssh</TT> connection.
It is careful with network bandwidth, and runs well over slow links
such as PPP connections. Transfers of small updates to large files are
optimized using a compression protocol similar to rsync.
<LI CLASS="li-itemize">Unison has a clear and precise specification, described
below. <LI CLASS="li-itemize">Unison is resilient to failure. It is careful to leave the
replicas and its own private structures in a sensible state at all
times, even in case of abnormal termination or communication
failures.
<LI CLASS="li-itemize">Unison is free; full source code is available under the GNU
Public License.
</UL>
<hr><!--TOC section Preface-->
<H2 CLASS="section"><A NAME="intro"></A>Preface</H2><!--SEC END -->
<!--TOC subsection People-->
<H3 CLASS="subsection"><A NAME="people"></A>People</H3><!--SEC END -->
<A HREF="http://www.cis.upenn.edu/~bcpierce/">Benjamin Pierce</A> leads the
Unison project.
The current version of Unison was designed and implemented by
<A HREF="http://www.research.att.com/~trevor/">Trevor Jim</A>,
<A HREF="http://www.cis.upenn.edu/~bcpierce/">Benjamin Pierce</A>,
and
J<>r<EFBFBD>me Vouillon,
with
<A HREF="http://www.inrialpes.fr/~aschmitt/">Alan Schmitt</A>,
Malo Denielou,
<A HREF="http://www.brics.dk/~zheyang/">Zhe Yang</A>,
Sylvain Gommier, and
Matthieu Goulay.
Our implementation of the
<A HREF="http://samba.org/rsync/">rsync</A>
protocol was built by
<A HREF="http://www.eecs.harvard.edu/~nr/">Norman Ramsey</A>
and Sylvain Gommier. It is is based on
<A HREF="http://samba.anu.edu.au/~tridge/">Andrew Tridgell</A>'s
<A HREF="http://samba.anu.edu.au/~tridge/phd_thesis.pdf">thesis work</A>
and inspired by his
<A HREF="http://samba.org/rsync/">rsync</A>
utility.
The mirroring and merging functionality was implemented by
Sylvain Roy and improved by Malo Denielou.
<A HREF="http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/">Jacques Garrigue</A>
contributed the original Gtk version of the user
interface; the Gtk2 version was built by Stephen Tse.
Sundar Balasubramaniam helped build a prototype implementation of
an earlier synchronizer in Java.
<A HREF="http://www.cis.upenn.edu/~ishin/">Insik Shin</A>
and
<A HREF="http://www.cis.upenn.edu/~lee/">Insup Lee</A> contributed design
ideas to this implementation.
<A HREF="http://research.microsoft.com/~fournet/">Cedric Fournet</A>
contributed to an even earlier prototype.<BR>
<BR>
<!--TOC subsection Mailing Lists and Bug Reporting-->
<H3 CLASS="subsection"><A NAME="lists"></A>Mailing Lists and Bug Reporting</H3><!--SEC END -->
<!--TOC paragraph Mailing Lists:-->
<H5 CLASS="paragraph">Mailing Lists:</H5><!--SEC END -->
Moderated mailing lists are available for bug reporting, announcements
of new versions, discussions among users, and discussions among
developers. See
<A HREF="http://www.cis.upenn.edu/~bcpierce/unison/lists.html"><TT>http://www.cis.upenn.edu/~bcpierce/unison/lists.html</TT></A> for more
information.<BR>
<BR>
<!--TOC subsection Development Status-->
<H3 CLASS="subsection"><A NAME="status"></A>Development Status</H3><!--SEC END -->
Unison is no longer under active development as a research
project. (Our research efforts are now focused on a follow-on
project called Harmony, described at
<A HREF="http://www.cis.upenn.edu/~bcpierce/harmony"><TT>http://www.cis.upenn.edu/~bcpierce/harmony</TT></A>.)
At this point, there is no one whose job it is to maintain Unison,
fix bugs, or answer questions.<BR>
<BR>
However, the original developers are all still using Unison daily. It
will continue to be maintained and supported for the foreseeable future,
and we will occasionally release new versions with bug fixes, small
improvements, and contributed patches.<BR>
<BR>
Reports of bugs affecting correctness or safety are of interest to many
people and will generally get high priority. Other bug reports will be
looked at as time permits. Bugs should be reported to the users list at
<A HREF="mailto:unison-users@yahoogroups.com"><TT>unison-users@yahoogroups.com</TT></A>. <BR>
<BR>
Feature requests are welcome, but will probably just be added to the
ever-growing todo list. They should also be sent to <A HREF="mailto:unison-users@yahoogroups.com"><TT>unison-users@yahoogroups.com</TT></A>.<BR>
<BR>
Patches are even more welcome. They should be sent to
<A HREF="mailto:unison-hackers@yahoogroups.com"><TT>unison-hackers@yahoogroups.com</TT></A>.
(Caveat: since safety and robustness are Unison's most important properties,
patches will be held to high standards of clear design and clean coding.)
If you want to contribute to Unison, start by downloading the developer
tarball from the download page. For some details on how the code is
organized, etc., see the file <TT>CONTRIB</TT>.<BR>
<BR>
<!--TOC subsection Copying-->
<H3 CLASS="subsection"><A NAME="copying"></A>Copying</H3><!--SEC END -->
Unison is free software. You are free to change and redistribute it
under the terms of the GNU General Public License. Please see the
file COPYING in the Unison distribution for more information.<BR>
<BR>
<!--TOC subsection Acknowledgements-->
<H3 CLASS="subsection"><A NAME="ack"></A>Acknowledgements</H3><!--SEC END -->
Work on Unison has been supported by the National Science Foundation
under grants CCR-9701826 and ITR-0113226, <EM>Principles and Practice of
Synchronization</EM>, and by University of Pennsylvania's Institute for
Research in Cognitive Science (IRCS).<BR>
<BR>
<hr><!--TOC section Installation-->
<H2 CLASS="section"><A NAME="install"></A>Installation</H2><!--SEC END -->
Unison is designed to be easy to install. The following sequence of
steps should get you a fully working installation in a few minutes. If
you run into trouble, you may find the suggestions on the
<A HREF="http://www.cis.upenn.edu/~bcpierce/unison/faq.html">Frequently Asked
Questions page</A> helpful. Pre-built binaries are available for a
variety of platforms.<BR>
<BR>
Unison can be used with either of two user interfaces:
<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
a simple textual interface, suitable for dumb terminals (and
running from scripts), and
<LI CLASS="li-enumerate">a more sophisticated grapical interface, based on Gtk2.
</OL>
You will need to install a copy of Unison on every machine that you
want to synchronize. However, you only need the version with a
graphical user interface (if you want a GUI at all) on the machine
where you're actually going to display the interface (the <EM>client</EM>
machine). Other machines that you synchronize with can get along just
fine with the textual version.<BR>
<BR>
<!--TOC subsection Downloading Unison-->
<H3 CLASS="subsection"><A NAME="download"></A>Downloading Unison</H3><!--SEC END -->
The Unison download site lives under
<A HREF="http://www.cis.upenn.edu/~bcpierce/unison"><TT>http://www.cis.upenn.edu/~bcpierce/unison</TT></A>.<BR>
<BR>
If a pre-built binary of Unison is available for the client machine's
architecture, just download it and put it somewhere in your search
path (if you're going to invoke it from the command line) or on your
desktop (if you'll be click-starting it).<BR>
<BR>
The executable file for the graphical version (with a name including
<CODE>gtkui</CODE>) actually provides <EM>both</EM> interfaces: the graphical one
appears by default, while the textual interface can be selected by including
<CODE>-ui text</CODE> on the command line. The <CODE>textui</CODE> executable
provides just the textual interface.<BR>
<BR>
If you don't see a pre-built executable for your architecture, you'll
need to build it yourself. See the <A HREF="#building">Building Unison</A> section.
There are also a small number of contributed ports to other
architectures that are not maintained by us. See the
<A HREF="http://www.cis.upenn.edu/~bcpierce/unison/download.html">Contributed
Ports page</A> to check what's available.<BR>
<BR>
Check to make sure that what you have downloaded is really executable.
Either click-start it, or type <FONT SIZE=4><TT>unison -version</TT></FONT> at the command
line. <BR>
<BR>
Unison can be used in three different modes: with different directories on a
single machine, with a remote machine over a direct socket connection, or
with a remote machine using <TT>ssh</TT> for authentication and secure
transfer. If you intend to use the last option, you may need to install
<TT>ssh</TT>; see the <A HREF="#ssh">Installing Ssh</A> section.<BR>
<BR>
<!--TOC subsection Running Unison-->
<H3 CLASS="subsection"><A NAME="afterinstall"></A>Running Unison</H3><!--SEC END -->
Once you've got Unison installed on at least one system, read
the <A HREF="#tutorial">Tutorial</A> section of the user manual (or type <FONT SIZE=4><TT>unison -doc
tutorial</TT></FONT>) for instructions on how to get started.<BR>
<BR>
<!--TOC subsection Upgrading-->
<H3 CLASS="subsection"><A NAME="upgrading"></A>Upgrading</H3><!--SEC END -->
Upgrading to a new version of Unison is as simple as throwing away the old
binary and installing the new one.<BR>
<BR>
Before upgrading, it is a good idea to run the <EM>old</EM> version one last
time, to make sure all your replicas are completely synchronized. A new
version of Unison will sometimes introduce a different format for the
archive files used to remember information about the previous state of the
replicas. In this case, the old archive will be ignored (not deleted &mdash; if
you roll back to the previous version of Unison, you will find the old
archives intact), which means that any differences between the replicas will
show up as conflicts that need to be resolved manually.<BR>
<BR>
<!--TOC subsection Building Unison from Scratch-->
<H3 CLASS="subsection"><A NAME="building"></A>Building Unison from Scratch</H3><!--SEC END -->
If a pre-built image is not available, you will need to compile it from
scratch; the sources are available from the same place as the binaries.<BR>
<BR>
In principle, Unison should work on any platform to which OCaml has been
ported and on which the <CODE>Unix</CODE> module is fully implemented. It has
been tested on many flavors of Windows (98, NT, 2000, XP) and Unix (OS X,
Solaris, Linux, FreeBSD), and on both 32- and 64-bit architectures.<BR>
<BR>
<!--TOC subsubsection Unix-->
<H4 CLASS="subsubsection"><A NAME="build-unix"></A>Unix</H4><!--SEC END -->
You'll need the Objective Caml compiler (version 3.07 or later), which is
available from <A HREF="http://caml.inria.fr"><TT>http://caml.inria.fr</TT></A>. Building and installing OCaml
on Unix systems is very straightforward; just follow the instructions in the
distribution. You'll probably want to build the native-code compiler in
addition to the bytecode compiler, as Unison runs much faster when compiled
to native code, but this is not absolutely necessary.
(Quick start: on many systems, the following sequence of commands will
get you a working and installed compiler: first do <TT>make world opt</TT>,
then <TT>su</TT> to root and do <TT>make install</TT>.)<BR>
<BR>
You'll also need the GNU <TT>make</TT> utility, standard on many Unix
systems. (Type <FONT SIZE=4><TT>make &ndash;version</TT></FONT> to check that you've got the
GNU version.)<BR>
<BR>
Once you've got OCaml installed, grab a copy of the Unison sources,
unzip and untar them, change to the new <FONT SIZE=4><TT>unison</TT></FONT> directory, and
type &#8220;<TT>make UISTYLE=text</TT>.&#8221;
The result should be an executable file called <FONT SIZE=4><TT>unison</TT></FONT>.
Type <FONT SIZE=4><TT>./unison</TT></FONT> to make sure the program is executable. You
should get back a usage message.<BR>
<BR>
If you want to build the graphical user interface, you will need to install
two additional things:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The Gtk2 libraries. These areavailable from
<A HREF="http://www.gtk.org"><TT>http://www.gtk.org</TT></A> and are standard on many Unix installations. <BR>
<BR>
<LI CLASS="li-itemize">The <TT>lablgtk2</TT> OCaml library. Grab the
developers' tarball from
<BLOCKQUOTE CLASS="quote">
<A HREF="http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html"><TT>http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html</TT></A>,
</BLOCKQUOTE>
untar it, and follow the instructions to build and install it.<BR>
<BR>
(Quick start: <TT>make configure</TT>, then <TT>make</TT>, then <TT>make
opt</TT>, then <TT>su</TT> and <TT>make install</TT>.)
</UL>
Now build unison. If your search paths are set up correctly, simply typing
<TT>make</TT>
again should build a <CODE>unison</CODE> executable with a Gtk2 graphical
interface. (In previous releases of Unison, it was necessary to add <TT>UISTYLE=gtk2</TT> to the 'make' command above. This requirement has been
removed: the makefile should detect automatically when lablgtk2 is
present and set this flag automatically.) <BR>
<BR>
Put the <CODE>unison</CODE> executable somewhere in your search path, either
by adding the Unison directory to your PATH variable or by copying the
executable to some standard directory where executables are stored.<BR>
<BR>
<!--TOC subsubsection Windows-->
<H4 CLASS="subsubsection"><A NAME="build-win"></A>Windows</H4><!--SEC END -->
Although the binary distribution should work on any version of Windows,
some people may want to build Unison from scratch on those systems too.<BR>
<BR>
<!--TOC paragraph Bytecode version:-->
<H5 CLASS="paragraph">Bytecode version:</H5><!--SEC END -->
The simpler but slower compilation option
to build a Unison executable is to build a bytecode version. You need
first install Windows version of the OCaml compiler (version 3.07 or
later, available from <A HREF="http://caml.inria.fr"><TT>http://caml.inria.fr</TT></A>). Then grab a copy
of Unison sources and type
<PRE CLASS="verbatim">
make NATIVE=false
</PRE>to compile the bytecode. The result should be an executable file called
<CODE>unison.exe</CODE>. <BR>
<BR>
<!--TOC paragraph Native version:-->
<H5 CLASS="paragraph">Native version:</H5><!--SEC END -->
Building a more efficient, native version of
Unison on Windows requires a little more work. See the file <TT>INSTALL.win32</TT> in the source code distribution.<BR>
<BR>
<!--TOC subsubsection Installation Options-->
<H4 CLASS="subsubsection"><A NAME="build-opts"></A>Installation Options</H4><!--SEC END -->
The <CODE>Makefile</CODE> in the distribution includes several switches that
can be used to control how Unison is built. Here are the most useful
ones:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Building with <CODE>NATIVE=true</CODE> uses the native-code OCaml
compiler, yielding an executable that will run quite a bit faster. We use
this for building distribution versions.
<LI CLASS="li-itemize">Building with <CODE>make DEBUGGING=true</CODE> generates debugging
symbols.
<LI CLASS="li-itemize">Building with <CODE>make STATIC=true</CODE> generates a (mostly)
statically linked executable. We use this for building distribution
versions, for portability.
</UL>
<hr><!--TOC section Tutorial-->
<H2 CLASS="section"><A NAME="tutorial"></A>Tutorial</H2><!--SEC END -->
<!--TOC subsection Preliminaries-->
<H3 CLASS="subsection"><A NAME="prelim"></A>Preliminaries</H3><!--SEC END -->
Unison can be used with either of two user interfaces:
<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
a straightforward textual interface and
<LI CLASS="li-enumerate">a more sophisticated graphical interface
</OL>
The textual interface is more convenient for running from scripts and
works on dumb terminals; the graphical interface is better for most
interactive use. For this tutorial, you can use either. If you are running
Unison from the command line, just typing <TT>unison</TT>
will select either the text or the graphical interface, depending on which
has been selected as default when the executable you are running was
built. You can force the text interface even if graphical is the default by
adding <TT>-ui text</TT>.
The other command-line arguments to both versions are identical. <BR>
<BR>
The graphical version can also be run directly by clicking on its icon, but
this may require a little set-up (see the <A HREF="#click">Click-starting
Unison</A> section). For this tutorial, we assume that you're starting it from the
command line.<BR>
<BR>
Unison can synchronize files and directories on a single machine, or
between two machines on a network. (The same program runs on both
machines; the only difference is which one is responsible for
displaying the user interface.) If you're only interested in a
single-machine setup, then let's call that machine the <EM>client</EM>. If
you're synchronizing two machines, let's call them <EM>client</EM> and
<EM>server</EM>.<BR>
<BR>
<!--TOC subsection Local Usage-->
<H3 CLASS="subsection"><A NAME="local"></A>Local Usage</H3><!--SEC END -->
Let's get the client machine set up first and see how to synchronize
two directories on a single machine.<BR>
<BR>
Follow the instructions in the <A HREF="#install">Installation</A> section to either
download or build an executable version of Unison, and install it
somewhere on your search path. (If you just want to use the textual user
interface, download the appropriate textui binary. If you just want to
the graphical interface&mdash;or if you will use both interfaces [the gtkui
binary actually has both compiled in]&mdash;then download the gtkui binary.)<BR>
<BR>
Create a small test directory <TT>a.tmp</TT> containing a couple of files
and/or subdirectories, e.g.,
<PRE CLASS="verbatim">
mkdir a.tmp
touch a.tmp/a a.tmp/b
mkdir a.tmp/d
touch a.tmp/d/f
</PRE>Copy this directory to b.tmp:
<PRE CLASS="verbatim">
cp -r a.tmp b.tmp
</PRE>
Now try synchronizing <TT>a.tmp</TT> and <TT>b.tmp</TT>. (Since they are
identical, synchronizing them won't propagate any changes, but Unison
will remember the current state of both directories so that it will be
able to tell next time what has changed.) Type:
<PRE CLASS="verbatim">
unison a.tmp b.tmp
</PRE>
<BR>
<EM>Textual Interface:</EM><UL CLASS="itemize"><LI CLASS="li-itemize">
You should see a message notifying you that all the files are actually
equal and then get returned to the command line.
</UL>
<BR>
<EM>Graphical Interface:</EM><UL CLASS="itemize"><LI CLASS="li-itemize">
You should get a big empty window with a message at the bottom
notifying you that all files are identical. Choose the Exit item from
the File menu to get back to the command line.
</UL>
Next, make some changes in a.tmp and/or b.tmp. For example:
<PRE CLASS="verbatim">
rm a.tmp/a
echo "Hello" &gt; a.tmp/b
echo "Hello" &gt; b.tmp/b
date &gt; b.tmp/c
echo "Hi there" &gt; a.tmp/d/h
echo "Hello there" &gt; b.tmp/d/h
</PRE>Run Unison again:
<PRE CLASS="verbatim">
unison a.tmp b.tmp
</PRE>
This time, the user interface will display only the files that have
changed. If a file has been modified in just one
replica, then it will be displayed with an arrow indicating the
direction that the change needs to be propagated. For example,
<PRE CLASS="verbatim">
&lt;--- new file c [f]
</PRE>indicates that the file <TT>c</TT> has been modified only in the second
replica, and that the default action is therefore to propagate the new
version to the first replica. To <B>f</B>ollw Unison's recommendation,
press the &#8220;f&#8221; at the prompt.<BR>
<BR>
If both replicas are modified and their contents are different, then
the changes are in conflict: <TT>&lt;-?-&gt;</TT> is displayed to indicate
that Unison needs guidance on which replica should override the
other.
<PRE CLASS="verbatim">
new file &lt;-?-&gt; new file d/h []
</PRE>By default, neither version will be propagated and both
replicas will remain as they are. <BR>
<BR>
If both replicas have been modified but their new contents are the same
(as with the file <TT>b</TT>), then no propagation is necessary and
nothing is shown. Unison simply notes that the file is up to date.<BR>
<BR>
These display conventions are used by both versions of the user
interface. The only difference lies in the way in which Unison's
default actions are either accepted or overriden by the user.<BR>
<BR>
<BR>
<EM>Textual Interface:</EM><UL CLASS="itemize"><LI CLASS="li-itemize">
The status of each modified file is displayed, in turn.
When the copies of a file in the two replicas are not identical, the
user interface will ask for instructions as to how to propagate the
change. If some default action is indicated (by an arrow), you can
simply press Return to go on to the next changed file. If you want to
do something different with this file, press &#8220;<CODE>&lt;</CODE>&#8221; or &#8220;<CODE>&gt;</CODE>&#8221; to force
the change to be propagated from right to left or from left to right,
or else press &#8220;<CODE>/</CODE>&#8221; to skip this file and leave both replicas alone.
When it reaches the end of the list of modified files, Unison will ask
you one more time whether it should proceed with the updates that have
been selected.<BR>
<BR>
When Unison stops to wait for input from the user, pressing &#8220;<CODE>?</CODE>&#8221;
will always give a list of possible responses and their meanings.
</UL>
<BR>
<EM>Graphical Interface:</EM><UL CLASS="itemize"><LI CLASS="li-itemize">
The main window shows all the files that have been modified in either
<TT>a.tmp</TT> or <TT>b.tmp</TT>. To override a default action (or to select
an action in the case when there is no default), first select the file, either
by clicking on its name or by using the up- and down-arrow keys. Then
press either the left-arrow or &#8220;<CODE>&lt;</CODE>&#8221; key (to cause the version in b.tmp to
propagate to a.tmp) or the right-arrow or &#8220;<CODE>&gt;</CODE>&#8221; key (which makes the a.tmp
version override b.tmp). <BR>
<BR>
Every keyboard command can also be invoked from the menus at the top
of the user interface. (Conversely, each menu item is annotated with
its keyboard equivalent, if it has one.)<BR>
<BR>
When you are satisfied with the directions for the propagation of changes
as shown in the main window, click the &#8220;Go&#8221; button to set them in
motion. A check sign will be displayed next to each filename
when the file has been dealt with.
</UL>
<!--TOC subsection Remote Usage-->
<H3 CLASS="subsection"><A NAME="remote"></A>Remote Usage</H3><!--SEC END -->
Next, we'll get Unison set up to synchronize replicas on two different
machines.<BR>
<BR>
Follow the instructions in the Installation section to download or
build an executable version of Unison on the server machine, and
install it somewhere on your search path. (It doesn't matter whether
you install the textual or graphical version, since the copy of Unison on
the server doesn't need to display any user interface at all.) <BR>
<BR>
It is important that the version of Unison installed on the server
machine is the same as the version of Unison on the client machine.
But some flexibility on the version of Unison at the client side can
be achieved by using the <CODE>-addversionno</CODE> option; see
the <A HREF="#prefs">Preferences</A> section.<BR>
<BR>
Now there is a decision to be made. Unison provides two methods for
communicating between the client and the server:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<EM>Remote shell method</EM>: To use this method, you must have
some way of invoking remote commands on the server from the client's
command line, using a facility such as <CODE>ssh</CODE>.
This method is more convenient (since there is no need to manually
start a &#8220;unison server&#8221; process on the server) and also more
secure (especially if you use <CODE>ssh</CODE>).<BR>
<BR>
<LI CLASS="li-itemize"><EM>Socket method</EM>: This method requires only that you can get
TCP packets from the client to the server and back. A draconian
firewall can prevent this, but otherwise it should work anywhere.
</UL>
Decide which of these you want to try, and continue with
the <A HREF="#rshmeth">Remote Shell Method</A> section or
the <A HREF="#socketmeth">Socket Method</A> section, as appropriate.<BR>
<BR>
<!--TOC subsection Remote Shell Method-->
<H3 CLASS="subsection"><A NAME="rshmeth"></A>Remote Shell Method</H3><!--SEC END -->
The standard remote shell facility on Unix systems is <CODE>ssh</CODE>, which provides the
same functionality as the older <CODE>rsh</CODE> but much better security. Ssh is available from
<A HREF="ftp://ftp.cs.hut.fi/pub/ssh/"><TT>ftp://ftp.cs.hut.fi/pub/ssh/</TT></A>; up-to-date binaries for some
architectures can also be found at
<A HREF="ftp://ftp.faqs.org/ssh/contrib"><TT>ftp://ftp.faqs.org/ssh/contrib</TT></A>. See section&nbsp;<A HREF="#ssh-win">A.2</A>
for installation instructions for the Windows version.<BR>
<BR>
Running
<CODE>ssh</CODE> requires some coordination between the client and server
machines to establish that the client is allowed to invoke commands on
the server; please refer to the or <CODE>ssh</CODE> documentation
for information on how to set this up. The examples in this section
use <CODE>ssh</CODE>, but you can substitute <CODE>rsh</CODE> for <CODE>ssh</CODE> if
you wish.<BR>
<BR>
First, test that we can invoke Unison on the server from the client.
Typing
<PRE>
ssh <I>remotehostname</I> unison -version
</PRE>
should print the same version information as running
<PRE CLASS="verbatim">
unison -version
</PRE>locally on the client. If remote execution fails, then either
something is wrong with your ssh setup (e.g., &#8220;permission denied&#8221;)
or else the search path that's being used when executing commands on
the server doesn't contain the <CODE>unison</CODE> executable (e.g.,
&#8220;command not found&#8221;).<BR>
<BR>
Create a test directory <TT>a.tmp</TT> in your home directory on the client
machine. <BR>
<BR>
Test that the local unison client can start and connect to the
remote server. Type
<PRE>
unison -testServer a.tmp ssh://<I>remotehostname</I>/a.tmp
</PRE>
Now cd to your home directory and type:
<PRE CLASS="verbatim">
unison a.tmp ssh://remotehostname/a.tmp
</PRE>The result should be that the entire directory <TT>a.tmp</TT> is propagated
from the client to your home directory on the server.<BR>
<BR>
After finishing the first synchronization, change a few files and try
synchronizing again. You should see similar results as in the local
case.<BR>
<BR>
If your user name on the server is not the same as on the client, you
need to specify it on the command line:
<PRE CLASS="verbatim">
unison a.tmp ssh://username@remotehostname/a.tmp
</PRE>
<I>Notes:</I>
<UL CLASS="itemize"><LI CLASS="li-itemize">
If you want to put <CODE>a.tmp</CODE> some place other than your home
directory on the remote host, you can give an absolute path for it by
adding an extra slash between <CODE>remotehostname</CODE> and the beginning
of the path:
<PRE CLASS="verbatim">
unison a.tmp ssh://remotehostname//absolute/path/to/a.tmp
</PRE><BR>
<BR>
<LI CLASS="li-itemize">You can give an explicit path for the <CODE>unison</CODE> executable
on the server by using the command-line option <FONT SIZE=4><TT>-servercmd
/full/path/name/of/unison</TT></FONT> or adding
<FONT SIZE=4><TT>servercmd=/full/path/name/of/unison</TT></FONT> to your profile (see
the <A HREF="#profile">Profile</A> section). Similarly, you can specify a
explicit path for the <CODE>ssh</CODE> program using the <FONT SIZE=4><TT>-sshcmd</TT></FONT>
option.
Extra arguments can be passed to <CODE>ssh</CODE> by setting the
<CODE>-sshargs</CODE> preference.
</UL>
<!--TOC subsection Socket Method-->
<H3 CLASS="subsection"><A NAME="socketmeth"></A>Socket Method</H3><!--SEC END -->
<BLOCKQUOTE CLASS="quote">
<B><FONT COLOR=red>Warning:</FONT></B> The socket method is
insecure: not only are the texts of your changes transmitted over
the network in unprotected form, it is also possible for anyone in
the world to connect to the server process and read out the contents
of your filesystem! (Of course, to do this they must understand the
protocol that Unison uses to communicate between client and server,
but all they need for this is a copy of the Unison sources.) The socket
method is provided only for expert users with specific needs; everyone
else should use the <CODE>ssh</CODE> method.
</BLOCKQUOTE>
To run Unison over a socket connection, you must start a Unison
daemon process on the server. This process runs continuously,
waiting for connections over a given socket from client machines
running Unison and processing their requests in turn.<BR>
<BR>
To start the daemon, type
<PRE CLASS="verbatim">
unison -socket NNNN
</PRE>on the server machine, where <TT>NNNN</TT> is the socket number that the
daemon should listen on for connections from clients. (<TT>NNNN</TT> can
be any large number that is not being used by some other program; if
<TT>NNNN</TT> is already in use, Unison will exit with an error
message.) Note that paths specified by the client will be interpreted
relative to the directory in which you start the server process; this
behavior is different from the ssh case, where the path is relative to
your home directory on the server.<BR>
<BR>
Create a test directory <TT>a.tmp</TT> in your home directory on the
client machine. Now type:
<PRE>
unison a.tmp socket://<I>remotehostname</I>:NNNN/a.tmp
</PRE>
The result should be that the entire directory <TT>a.tmp</TT> is
propagated from the client to the server (<TT>a.tmp</TT> will be
created on the server in the directory that the server was started
from).
After finishing the first synchronization, change a few files and try
synchronizing again. You should see similar results as in the local
case.<BR>
<BR>
Since the socket method is not used by many people, its functionality is
rather limited. For example, the server can only deal with one client at a
time. <BR>
<BR>
<!--TOC subsection Using Unison for All Your Files-->
<H3 CLASS="subsection"><A NAME="usingit"></A>Using Unison for All Your Files</H3><!--SEC END -->
Once you are comfortable with the basic operation of Unison, you may
find yourself wanting to use it regularly to synchronize your commonly
used files. There are several possible ways of going about this:
<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
Synchronize your whole home directory, using the Ignore facility
(see the <A HREF="#ignore">Ignore</A> section)
to avoid synchronizing temporary files and things that only belong on
one host.
<LI CLASS="li-enumerate">Create a subdirectory called <TT>shared</TT> (or <TT>current</TT>, or
whatever) in your home directory on each host, and put all the files
you want to synchronize into this directory.
<LI CLASS="li-enumerate">Create a subdirectory called <TT>shared</TT> (or <TT>current</TT>, or
whatever) in your home directory on each host, and put <EM>links to</EM>
all the files you want to synchronize into this directory. Use the
<TT>follow</TT> preference (see the <A HREF="#symlinks">Symbolic Links</A> section) to make
Unison treat these links as transparent.
<LI CLASS="li-enumerate">Make your home directory the root of the synchronization, but
tell Unison to synchronize only some of the files and subdirectories
within it on any given run. This can be accomplished by using the <TT>-path</TT> switch
on the command line:
<PRE>
unison /home/<I>username</I> ssh://<I>remotehost</I>//home/<I>username</I> -path shared
</PRE>
The <TT>-path</TT> option can be used as many times as needed, to
synchronize several files or subdirectories:
<PRE>
unison /home/<I>username</I> ssh://<I>remotehost</I>//home/<I>username</I> <CODE>\</CODE>
-path shared <CODE>\</CODE>
-path pub <CODE>\</CODE>
-path .netscape/bookmarks.html
</PRE>
These <CODE>-path</CODE> arguments can also be put in your preference file.
See the <A HREF="#prefs">Preferences</A> section for an example.
</OL>
Most people find that they only need to maintain a profile (or
profiles) on one of the hosts that they synchronize, since Unison is
always initiated from this host. (For example, if you're
synchronizing a laptop with a fileserver, you'll probably always run
Unison on the laptop.) This is a bit different from the usual
situation with asymmetric mirroring programs like <CODE>rdist</CODE>, where
the mirroring operation typically needs to be initiated from the
machine with the most recent changes. the <A HREF="#profile">Profile</A> section
covers the syntax of Unison profiles, together with some sample profiles.<BR>
<BR>
Some tips on improving Unison's performance can be found on the
<A HREF="http://www.cis.upenn.edu/~bcpierce/unison/faq.html">Frequently
Asked Questions page</A>.<BR>
<BR>
<!--TOC subsection Using Unison to Synchronize More Than Two Machines-->
<H3 CLASS="subsection"><A NAME="usingmultiple"></A>Using Unison to Synchronize More Than Two Machines</H3><!--SEC END -->
Unison is designed for synchronizing pairs of replicas. However, it is
possible to use it to keep larger groups of machines in sync by performing
multiple pairwise synchronizations. <BR>
<BR>
If you need to do this, the most reliable way to set things up is to
organize the machines into a &#8220;star topology,&#8221; with one machine designated
as the &#8220;hub&#8221; and the rest as &#8220;spokes,&#8221; and with each spoke machine
synchronizing only with the hub. The big advantage of the star topology is
that it eliminates the possibility of confusing &#8220;spurious conflicts&#8221;
arising from the fact that a separate archive is maintained by Unison for
every pair of hosts that it synchronizes.<BR>
<BR>
<!--TOC subsection Going Further-->
<H3 CLASS="subsection"><A NAME="further"></A>Going Further</H3><!--SEC END -->
On-line documentation for the various features of Unison
can be obtained either by typing
<PRE CLASS="verbatim">
unison -doc topics
</PRE>at the command line, or by selecting the Help menu in the graphical
user interface.
The on-line information and the printed manual are essentially identical.
<BR>
<BR>
If you use Unison regularly, you should subscribe to one of the mailing
lists, to receive announcements of new versions. See
the <A HREF="#lists">Mailing Lists</A> section. <BR>
<BR>
<hr><!--TOC section Basic Concepts-->
<H2 CLASS="section"><A NAME="basics"></A>Basic Concepts</H2><!--SEC END -->
To understand how Unison works, it is necessary to discuss a few
straightforward concepts.
These concepts are developed more rigorously and at more length in a number
of papers, available at <A HREF="http://www.cis.upenn.edu/~bcpierce/papers"><TT>http://www.cis.upenn.edu/~bcpierce/papers</TT></A>.
But the informal presentation here should be enough for most users.<BR>
<BR>
<!--TOC subsection Roots-->
<H3 CLASS="subsection"><A NAME="roots"></A>Roots</H3><!--SEC END -->
A replica's <EM>root</EM> tells Unison where to find a set of files to be
synchronized, either on the local machine or on a remote host.
For example,
<PRE>
<I>relative/path/of/root</I>
</PRE>
specifies a local root relative to the directory where Unison is
started, while
<PRE>
/<I>absolute/path/of/root</I>
</PRE>
specifies a root relative to the top of the local filesystem,
independent of where Unison is running. Remote roots can begin with
<CODE>ssh://</CODE>,
<CODE>rsh://</CODE>
to indicate that the remote server should be started with rsh or ssh:
<PRE>
ssh://<I>remotehost</I>//<I>absolute/path/of/root</I>
rsh://<I>user</I>@<I>remotehost</I>/<I>relative/path/of/root</I>
</PRE>
If the remote server is already running (in the socket mode), then the syntax
<PRE>
socket://<I>remotehost</I>:<I>portnum</I>//<I>absolute/path/of/root</I>
socket://<I>remotehost</I>:<I>portnum</I>/<I>relative/path/of/root</I>
</PRE>
is used to specify the hostname and the port that the client Unison should
use to contact it.<BR>
<BR>
The syntax for roots is based on that of URIs (described in RFC 2396).
The full grammar is:
<PRE>
<I>replica</I> ::= [<I>protocol</I>:]//[<I>user</I>@][<I>host</I>][:<I>port</I>][/<I>path</I>]
| <I>path</I>
<I>protocol</I> ::= file
| socket
| ssh
| rsh
<I>user</I> ::= [-_a-zA-Z0-9]+
<I>host</I> ::= [-_a-zA-Z0-9.]+
<I>port</I> ::= [0-9]+
</PRE>
When <CODE>path</CODE> is given without any protocol prefix, the protocol is
assumed to be <CODE>file:</CODE>. Under Windows, it is possible to
synchronize with a remote directory using the <CODE>file:</CODE> protocol over
the Windows Network Neighborhood. For example,
<PRE CLASS="verbatim">
unison foo //host/drive/bar
</PRE>synchronizes the local directory <CODE>foo</CODE> with the directory
<CODE>drive:\bar</CODE> on the machine <CODE>host</CODE>, provided that <CODE>host</CODE>
is accessible via Network Neighborhood. When the <CODE>file:</CODE> protocol
is used in this way, there is no need for a Unison server to be running
on the remote host. However, running Unison this way is only a good
idea if the remote host is reached by a very fast network connection,
since the full contents of every file in the remote replica will have to
be transferred to the local machine to detect updates.<BR>
<BR>
The names of roots are <EM>canonized</EM> by Unison before it uses them
to compute the names of the corresponding archive files, so <TT>//saul//home/bcpierce/common</TT> and <TT>//saul.cis.upenn.edu/common</TT>
will be recognized as the same replica under different names.<BR>
<BR>
<!--TOC subsection Paths-->
<H3 CLASS="subsection"><A NAME="paths"></A>Paths</H3><!--SEC END -->
A <EM>path</EM> refers to a point <EM>within</EM> a set of files being
synchronized; it is specified relative to the root of the replica.<BR>
<BR>
Formally, a path is just a sequence of names, separated by <CODE>/</CODE>.
Note that the path separator character is always a forward slash, no
matter what operating system Unison is running on. Forward slashes
are converted to backslashes as necessary when paths are converted to
filenames in the local filesystem on a particular host.
(For example, suppose that we run Unison on a Windows system, synchronizing
the local root <CODE>c:\pierce</CODE> with the root
<CODE>ssh://saul.cis.upenn.edu/home/bcpierce</CODE> on a Unix server. Then
the path <CODE>current/todo.txt</CODE> refers to the file
<CODE>c:\pierce\current\todo.txt</CODE> on the client and
<CODE>/home/bcpierce/current/todo.txt</CODE> on the server.)<BR>
<BR>
The empty path (i.e., the empty sequence of names) denotes the whole
replica. Unison displays the empty path as &#8220;<CODE>[root]</CODE>.&#8221;<BR>
<BR>
If <CODE>p</CODE> is a path and <CODE>q</CODE> is a path beginning with <CODE>p</CODE>, then
<CODE>q</CODE> is said to be a <EM>descendant</EM> of <CODE>p</CODE>. (Each path is also a
descendant of itself.)<BR>
<BR>
<!--TOC subsection What is an Update?-->
<H3 CLASS="subsection"><A NAME="updates"></A>What is an Update?</H3><!--SEC END -->
The <EM>contents</EM> of a path <CODE>p</CODE> in a particular replica could be a
file, a directory, a symbolic link, or absent (if <CODE>p</CODE> does not
refer to anything at all in that replica). More specifically:
<UL CLASS="itemize"><LI CLASS="li-itemize">
If <CODE>p</CODE> refers to an ordinary file, then the
contents of <CODE>p</CODE> are the actual contents of this file (a string of bytes)
plus the current permission bits of the file.
<LI CLASS="li-itemize">If <CODE>p</CODE> refers to a symbolic link, then the contents of <CODE>p</CODE>
are just the string specifying where the link points.
<LI CLASS="li-itemize">If <CODE>p</CODE> refers to a directory, then the
contents of <CODE>p</CODE> are just the token &#8220;DIRECTORY&#8221; plus the current
permission bits of the directory.
<LI CLASS="li-itemize">If <CODE>p</CODE> does not refer to anything in this replica, then the
contents of <CODE>p</CODE> are the token &#8220;ABSENT.&#8221;
</UL>
Unison keeps a record of the contents of each path after each
successful synchronization of that path (i.e., it remembers the
contents at the last moment when they were the same in the two
replicas). <BR>
<BR>
We say that a path is <EM>updated</EM> (in some replica) if its current
contents are different from its contents the last time it was successfully
synchronized. Note that whether a path is updated has nothing to do with
its last modification time&mdash;Unison considers only the contents when
determining whether an update has occurred. This means that touching a file
without changing its contents will <EM>not</EM> be recognized as an update. A
file can even be changed several times and then changed back to its original
contents; as long as Unison is only run at the end of this process, no
update will be recognized.<BR>
<BR>
What Unison actually calculates is a close approximation to this
definition; see the <A HREF="#caveats">Caveats and Shortcomings</A> section.<BR>
<BR>
<!--TOC subsection What is a Conflict?-->
<H3 CLASS="subsection"><A NAME="conflicts"></A>What is a Conflict?</H3><!--SEC END -->
A path is said to be <EM>conflicting</EM> if the following conditions all hold:
<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
it has been updated in one replica,
<LI CLASS="li-enumerate">it or any of its descendants has been updated in the other
replica,
and
<LI CLASS="li-enumerate">its contents in the two replicas are not identical.
</OL>
<!--TOC subsection Reconciliation-->
<H3 CLASS="subsection"><A NAME="recon"></A>Reconciliation</H3><!--SEC END -->
Unison operates in several distinct stages:
<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
On each host, it compares its archive file (which records
the state of each path in the replica when it was last synchronized)
with the current contents of the replica, to determine which paths
have been updated.
<LI CLASS="li-enumerate">It checks for &#8220;false conflicts&#8221; &mdash; paths that have been
updated on both replicas, but whose current values are identical.
These paths are silently marked as synchronized in the archive files
in both replicas.
<LI CLASS="li-enumerate">It displays all the updated paths to the user. For updates that
do not conflict, it suggests a default action (propagating the new
contents from the updated replica to the other). Conflicting updates
are just displayed. The user is given an opportunity to examine the
current state of affairs, change the default actions for
nonconflicting updates, and choose actions for conflicting updates.
<LI CLASS="li-enumerate">It performs the selected actions, one at a time. Each action is
performed by first transferring the new contents to a temporary file
on the receiving host, then atomically moving them into place.
<LI CLASS="li-enumerate">It updates its archive files to reflect the new state of the
replicas.
</OL>
<!--TOC subsection Invariants-->
<H3 CLASS="subsection"><A NAME="failures"></A>Invariants</H3><!--SEC END -->
Given the importance and delicacy of the job that it performs, it is
important to understand both what a synchronizer does under normal
conditions and what can happen under unusual conditions such as system
crashes and communication failures. <BR>
<BR>
Unison is careful to protect both its internal state and the state of
the replicas at every point in this process. Specifically, the
following guarantees are enforced:
<UL CLASS="itemize"><LI CLASS="li-itemize">
At every moment, each path in each replica has either (1) its <EM>original</EM> contents (i.e., no change at all has been made to this
path), or (2) its <EM>correct</EM> final contents (i.e., the value that the
user expected to be propagated from the other replica).
<LI CLASS="li-itemize">At every moment, the information stored on disk about Unison's
private state can be either (1) unchanged, or (2) updated to reflect
those paths that have been successfully synchronized.
</UL>
The upshot is that it is safe to interrupt Unison at any time, either
manually or accidentally. [Caveat: the above is <EM>almost</EM> true there
are occasionally brief periods where it is not (and, because of
shortcoming of the Posix filesystem API, cannot be); in particular, when
it is copying a file onto a directory or vice versa, it must first move
the original contents out of the way. If Unison gets
interrupted during one of these periods, some manual cleanup may be
required. In this case, a file called <TT>DANGER.README</TT> will be left
in your home directory, containing information about the operation that
was interrupted. The next time you try to run Unison, it will notice this
file and warn you about it.]<BR>
<BR>
If an interruption happens while it is propagating updates, then there
may be some paths for which an update has been propagated but which
have not been marked as synchronized in Unison's archives. This is no
problem: the next time Unison runs, it will detect changes to these
paths in both replicas, notice that the contents are now equal, and
mark the paths as successfully updated when it writes back its private
state at the end of this run.<BR>
<BR>
If Unison is interrupted, it may sometimes leave temporary working files
(with suffix <CODE>.tmp</CODE>) in the replicas. It is safe to delete these
files. Also, if the <CODE>backups</CODE> flag is set, Unison will
leave around old versions of files that it overwrites, with names like
<CODE>file.0.unison.bak</CODE>. These can be deleted safely when they are no
longer wanted.<BR>
<BR>
Unison is not bothered by clock skew between the different hosts on
which it is running. It only performs comparisons between timestamps
obtained from the same host, and the only assumption it makes about
them is that the clock on each system always runs forward.<BR>
<BR>
If Unison finds that its archive files have been deleted (or that the
archive format has changed and they cannot be read, or that they don't
exist because this is the first run of Unison on these particular
roots), it takes a conservative approach: it behaves as though the
replicas had both been completely empty at the point of the last
synchronization. The effect of this is that, on the first run, files
that exist in only one replica will be propagated to the other, while
files that exist in both replicas but are unequal will be marked as
conflicting. <BR>
<BR>
Touching a file without changing its contents should never affect whether or
not Unison does an update. (When running with the fastcheck preference set
to true&mdash;the default on Unix systems&mdash;Unison uses file modtimes for a
quick first pass to tell which files have definitely not changed; then, for
each file that might have changed, it computes a fingerprint of the file's
contents and compares it against the last-synchronized contents. Also, the
<CODE>-times</CODE> option allows you to synchronize file times, but it does not
cause identical files to be changed; Unison will only modify the file
times.)<BR>
<BR>
It is safe to &#8220;brainwash&#8221; Unison by deleting its archive files
<EM>on both replicas</EM>. The next time it runs, it will assume that
all the files it sees in the replicas are new. <BR>
<BR>
It is safe to modify files while Unison is working. If Unison
discovers that it has propagated an out-of-date change, or that the
file it is updating has changed on the target replica, it will signal
a failure for that file. Run Unison again to propagate the latest
change.
<BR>
<BR>
Changes to the ignore patterns from the user interface (e.g., using
the `i' key) are immediately reflected in the current profile.<BR>
<BR>
<!--TOC subsection Caveats and Shortcomings-->
<H3 CLASS="subsection"><A NAME="caveats"></A>Caveats and Shortcomings</H3><!--SEC END -->
Here are some things to be careful of when using Unison.
<UL CLASS="itemize"><LI CLASS="li-itemize">
In the interests of speed, the update detection algorithm may
(depending on which OS architecture that you run Unison on)
actually use an approximation to the definition given in
the <A HREF="#updates">What is an Update?</A> section. <BR>
<BR>
In particular, the Unix
implementation does not compare the actual contents of files to their
previous contents, but simply looks at each file's inode number and
modtime; if neither of these have changed, then it concludes that the
file has not been changed.<BR>
<BR>
Under normal circumstances, this approximation is safe, in the sense
that it may sometimes detect &#8220;false updates&#8221; will never miss a real
one. However, it is possible to fool it, for example by using
<CODE>retouch</CODE> to change a file's modtime back to a time in the past.
<BR>
<BR>
<LI CLASS="li-itemize">If you synchronize between a single-user filesystem and a shared
Unix server, you should pay attention to your permission bits: by
default, Unison will synchronize permissions verbatim, which may leave
group-writable files on the server that could be written over by a lot of
people. <BR>
<BR>
You can control this by setting your <CODE>umask</CODE> on both computers to
something like 022, masking out the &#8220;world write&#8221; and &#8220;group write&#8221;
permission bits. <BR>
<BR>
Unison does not synchronize the <CODE>setuid</CODE> and <CODE>setgid</CODE> bits, for
security. <BR>
<BR>
<LI CLASS="li-itemize">The graphical user interface is single-threaded. This
means that if Unison is performing some long-running operation, the
display will not be repainted until it finishes. We recommend not
trying to do anything with the user interface while Unison is in the
middle of detecting changes or propagating files.<BR>
<BR>
<LI CLASS="li-itemize">Unison does not understand hard links.<BR>
<BR>
<LI CLASS="li-itemize">It is important to be a little careful when renaming directories
containing &#8220;ignore&#8221;d files. <BR>
<BR>
For example, suppose Unison is synchronizing directory A between the two
machines called the &#8220;local&#8221; and the &#8220;remote&#8221; machine; suppose directory
A contains a subdirectory D; and suppose D on the local machine contains a
file or subdirectory P that matches an ignore directive in the profile used
to synchronize. Thus path A/D/P exists on the local machine but not on the
remote machine.<BR>
<BR>
If D is renamed to D' on the remote machine, and this change is
propagated to the local machine, all such files or subdirectories P
will be deleted. This is because Unison sees the rename as a delete and a
separate create: it deletes the old directory (including the ignored files)
and creates a new one (<EM>not</EM> including the ignored files, since they
are completely invisible to it).
</UL>
<hr><!--TOC section Reference Guide-->
<H2 CLASS="section"><A NAME="reference"></A>Reference Guide</H2><!--SEC END -->
This section covers the features of Unison in detail. <BR>
<BR>
<!--TOC subsection Running Unison-->
<H3 CLASS="subsection"><A NAME="running"></A>Running Unison</H3><!--SEC END -->
There are several ways to start Unison.
<UL CLASS="itemize"><LI CLASS="li-itemize">
Typing &#8220;<TT>unison <I>profile</I></TT>&#8221; on the command line. Unison
will look for a file <TT><I>profile</I></TT><TT>.prf</TT> in the <CODE>.unison</CODE>
directory. If this file does not specify a pair of roots, Unison will
prompt for them and add them to the information specified by the profile.
<LI CLASS="li-itemize">Typing &#8220;<TT>unison <I>profile</I></TT><TT> <I>root1</I></TT><TT> <I>root2</I></TT>&#8221; on the command
line.
In this case, Unison will use <TT><I>profile</I></TT>, which should not contain
any <TT>root</TT> directives.
<LI CLASS="li-itemize">Typing &#8220;<TT>unison <I>root1</I></TT><TT> <I>root2</I></TT>&#8221; on the command line. This
has the same effect as typing &#8220;<TT>unison default <I>root1</I></TT><TT> <I>root2</I></TT>.&#8221;
<LI CLASS="li-itemize">Typing just &#8220;<TT>unison</TT>&#8221; (or invoking Unison by clicking on
a desktop icon). In this case, Unison will ask for the profile to use
for synchronization (or create a new one, if necessary).
</UL>
<!--TOC subsection The <TT>.unison</TT> Directory-->
<H3 CLASS="subsection"><A NAME="unisondir"></A>The <TT>.unison</TT> Directory</H3><!--SEC END -->
Unison stores a variety of information in a private directory on each
host. If the environment variable <TT>UNISON</TT> is defined, then its
value will be used as the name of this directory. If <TT>UNISON</TT> is
not defined, then the name of the directory depends on which
operating system you are using. In Unix, the default is to use
<TT>$HOME/.unison</TT>.
In Windows, if the environment variable
<TT>USERPROFILE</TT> is defined, then the directory will be
<TT>$USERPROFILE\.unison</TT>;
otherwise if <TT>HOME</TT> is defined, it will be
<TT>$HOME\.unison</TT>;
otherwise, it will be
<TT>c:\.unison</TT>.<BR>
<BR>
The archive file for each replica is found in the <TT>.unison</TT>
directory on that replica's host. Profiles (described below) are
always taken from the <TT>.unison</TT> directory on the client host.<BR>
<BR>
Note that Unison maintains a completely different set of archive files
for each pair of roots.<BR>
<BR>
We do not recommend synchronizing the whole <TT>.unison</TT> directory, as this
will involve frequent propagation of large archive files. It should be safe
to do it, though, if you really want to. Synchronizing just the profile
files in the <TT>.unison</TT> directory is definitely OK.<BR>
<BR>
<!--TOC subsection Archive Files-->
<H3 CLASS="subsection"><A NAME="archives"></A>Archive Files</H3><!--SEC END -->
The name of the archive file on each replica is calculated from
<UL CLASS="itemize"><LI CLASS="li-itemize">
the <EM>canonical names</EM> of all the hosts (short names like
<CODE>saul</CODE> are converted into full addresses like <CODE>saul.cis.upenn.edu</CODE>),
<LI CLASS="li-itemize">the paths to the replicas on all the hosts (again, relative
pathnames, symbolic links, etc. are converted into full, absolute paths), and
<LI CLASS="li-itemize">an internal version number that is changed whenever a new Unison
release changes the format of the information stored in the archive.
</UL>
This method should work well for most users. However, it is occasionally
useful to change the way archive names are generated. Unison provides
two ways of doing this.<BR>
<BR>
The function that finds the canonical hostname of the local host (which
is used, for example, in calculating the name of the archive file used to
remember which files have been synchronized) normally uses the
<CODE>gethostname</CODE> operating system call. However, if the environment
variable <CODE>UNISONLOCALHOSTNAME</CODE> is set, its value will be used
instead. This makes it easier to use Unison in situations where a
machine's name changes frequently (e.g., because it is a laptop and gets
moved around a lot).<BR>
<BR>
A more powerful way of changing archive names is provided by the
<CODE>rootalias</CODE> preference. The preference file may contain any number of
lines of the form:
<PRE>
rootalias = //<I>hostnameA</I>//<I>path-to-replicaA</I> -&gt; //<I>hostnameB</I>//<I>path-to-replicaB</I>
</PRE>
When calculating the name of the archive files for a given pair of roots,
Unison replaces any root that matches the left-hand side of any rootalias
rule by the corresponding right-hand side.<BR>
<BR>
So, if you need to relocate a root on one of the hosts, you can add a
rule of the form:
<PRE>
rootalias = //<I>new-hostname</I>//<I>new-path</I> -&gt; //<I>old-hostname</I>//<I>old-path</I>
</PRE>
<EM>Warning</EM>: The <CODE>rootalias</CODE> option is dangerous and should only
be used if you are sure you know what you're doing. In particular, it
should only be used if you are positive that either (1) both the original
root and the new alias refer to the same set of files, or (2) the files
have been relocated so that the original name is now invalid and will
never be used again. (If the original root and the alias refer to
different sets of files, Unison's update detector could get confused.)
After introducing a new <CODE>rootalias</CODE>, it is a good idea to run Unison
a few times interactively (with the <CODE>batch</CODE> flag off, etc.) and
carefully check that things look reasonable&mdash;in particular, that update
detection is working as expected.<BR>
<BR>
<!--TOC subsection Preferences-->
<H3 CLASS="subsection"><A NAME="prefs"></A>Preferences</H3><!--SEC END -->
Many details of Unison's behavior are configurable by user-settable
&#8220;preferences.&#8221; <BR>
<BR>
Some preferences are boolean-valued; these are often called <EM>flags</EM>.
Others take numeric or string arguments, indicated in the preferences
list by <TT>n</TT> or <TT>xxx</TT>. Most of the string preferences can be
given several times; the arguments are accumulated into a list
internally.<BR>
<BR>
There are two ways to set the values of preferences: temporarily, by
providing command-line arguments to a particular run of Unison, or
permanently, by adding commands to a <EM>profile</EM> in the <TT>.unison</TT>
directory on the client host. The order of preferences (either on the
command line or in preference files) is not significant. On the command
line, preferences and other arguments (the profile name and roots) can be
intermixed in any order.<BR>
<BR>
To set the value of a preference <TT>p</TT> from the command line, add an
argument <TT>-p</TT> (for a boolean flag) or <TT>-p n</TT> or <TT>-p xxx</TT> (for
a numeric or string preference) anywhere on the command line. To set a
boolean flag to <CODE>false</CODE> on the command line, use <TT>-p=false</TT>.<BR>
<BR>
Here are all the preferences supported by Unison. This list can be
obtained by typing <TT>unison -help</TT>.
<BLOCKQUOTE CLASS="quote">
<PRE CLASS="verbatim">
Usage: unison [options]
or unison root1 root2 [options]
or unison profilename [options]
Options:
-addprefsto xxx file to add new prefs to
-addversionno add version number to name of unison executable on server
-auto automatically accept default actions
-backup xxx add a pattern to the backup list
-backupcurrent xxx add a pattern to the backupcurrent list
-backupcurrentnot xxx add a pattern to the backupcurrentnot list
-backupdir xxx Directory for storing centralized backups
-backuplocation xxx where backups are stored ('local' or 'central')
-backupnot xxx add a pattern to the backupnot list
-backupprefix xxx prefix for the names of backup files
-backups keep backup copies of all files (see also 'backup')
-backupsuffix xxx a suffix to be added to names of backup files
-batch batch mode: ask no questions at all
-confirmmerge ask for confirmation before commiting results of a merge
-contactquietly Suppress the 'contacting server' message during startup
-debug xxx debug module xxx ('all' -&gt; everything, 'verbose' -&gt; more)
-doc xxx show documentation ('-doc topics' lists topics)
-dumbtty do not try to change terminal settings in text UI
-fastcheck xxx do fast update detection (`true', `false', or `default')
-follow xxx add a pattern to the follow list
-force xxx force changes from this replica to the other
-group synchronize group
-height n height (in lines) of main window in graphical interface
-host xxx bind the socket to this host name in server socket mode
-ignore xxx add a pattern to the ignore list
-ignorecase xxx ignore upper/lowercase in filenames (`true', `false', or `default')
-ignorelocks ignore locks left over from previous run (dangerous!)
-ignorenot xxx add a pattern to the ignorenot list
-immutable xxx add a pattern to the immutable list
-immutablenot xxx add a pattern to the immutablenot list
-key xxx define a keyboard shortcut for this profile
-killserver kill server when done (even when using sockets)
-label xxx provide a descriptive string label for this profile
-log record actions in file specified by logfile preference
-logfile xxx Log file name
-maxbackups n number of backed up versions of a file
-maxthreads n maximum number of simultaneous file transfers
-merge xxx add a pattern to the merge list
-mergebatch xxx add a pattern to the mergebatch list
-numericids don't map uid/gid values by user/group names
-owner synchronize owner
-path xxx path to synchronize
-perms n part of the permissions which is synchronized
-prefer xxx choose this replica's version for conflicting changes
-pretendwin Use creation times for detecting updates
-repeat xxx synchronize repeatedly (text interface only)
-retry n re-try failed synchronizations N times (text interface only)
-root xxx root of a replica
-rootalias xxx Register alias for canonical root names
-rsrc xxx synchronize resource forks and HFS meta-data (`true', `false', or `default')
-rsync activate the rsync transfer mode
-servercmd xxx name of unison executable on remote server
-showarchive show name of archive and 'true names' (for rootalias) of roots
-silent print nothing (except error messages)
-socket xxx act as a server on a socket
-sortbysize list changed files by size, not name
-sortfirst xxx add a pattern to the sortfirst list
-sortlast xxx add a pattern to the sortlast list
-sortnewfirst list new before changed files
-sshargs xxx other arguments (if any) for remote shell command
-sshcmd xxx path to the ssh executable
-terse suppress status messages
-testserver exit immediately after the connection to the server
-times synchronize modification times
-ui xxx select user interface ('text' or 'graphic'); command-line only
-version print version and exit
-xferbycopying optimize transfers using local copies, if possible
</PRE>
</BLOCKQUOTE>
Here, in more detail, are what they do. Many are discussed in even greater
detail in other sections of the manual.
<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description">
<B>addprefsto <TT>xxx</TT></B><DD CLASS="dd-description">
By default, new preferences added by Unison (e.g., new <CODE>ignore</CODE> clauses) will be appended to whatever preference file Unison was told to load at the beginning of the run. Setting the preference <TT>addprefsto <I>filename</I></TT> makes Unison add new preferences to the file named <TT><I>filename</I></TT> instead.<BR>
<BR>
<DT CLASS="dt-description"><B>addversionno </B><DD CLASS="dd-description">
When this flag is set to <TT>true</TT>, Unison will use <TT>unison-<I>currentversionnumber</I></TT> instead of just <CODE>unison</CODE> as the remote server command. This allows multiple binaries for different versions of unison to coexist conveniently on the same server: whichever version is run on the client, the same version will be selected on the server.<BR>
<BR>
<DT CLASS="dt-description"><B>auto </B><DD CLASS="dd-description">
When set to <TT>true</TT>, this flag causes the user interface to skip asking for confirmations on non-conflicting changes. (More precisely, when the user interface is done setting the propagation direction for one entry and is about to move to the next, it will skip over all non-conflicting entries and go directly to the next conflict.)<BR>
<BR>
<DT CLASS="dt-description"><B>backup <TT>xxx</TT></B><DD CLASS="dd-description">
Including the preference <TT>-backup <I>pathspec</I></TT> causes Unison to keep backup files for each path that matches <TT><I>pathspec</I></TT>. These backup files are kept in the directory specified by the <CODE>backuplocation</CODE> preference. The backups are named according to the <CODE>backupprefix</CODE> and <CODE>backupsuffix</CODE> preferences. The number of versions that are kept is determined by the <CODE>maxbackups</CODE> preference.<BR>
<BR>
The syntax of <TT><I>pathspec</I></TT> is described in the <A HREF="#pathspec">Path Specification</A> section.<BR>
<BR>
<DT CLASS="dt-description"><B>backupcurrent <TT>xxx</TT></B><DD CLASS="dd-description">
Including the preference <TT>-backupcurrent <I>pathspec</I></TT> causes Unison to keep a backup of the <EM>current</EM> version of every file matching <TT><I>pathspec</I></TT>. This file will be saved as a backup with version number 000. Such backups can be used as inputs to external merging programs, for instance. See the documentatation for the <CODE>merge</CODE> preference. For more details, see the <A HREF="#merge">Merging Conflicting Versions</A> section.<BR>
<BR>
The syntax of <TT><I>pathspec</I></TT> is described in the <A HREF="#pathspec">Path Specification</A> section.<BR>
<BR>
<DT CLASS="dt-description"><B>backupcurrentnot <TT>xxx</TT></B><DD CLASS="dd-description">
Exceptions to <CODE>backupcurrent</CODE>, like the <CODE>ignorenot</CODE> preference.<BR>
<BR>
<DT CLASS="dt-description"><B>backupdir <TT>xxx</TT></B><DD CLASS="dd-description">
If this preference is set, Unison will use it as the name of the directory used to store backup files specified by the <TT>backup</TT> preference, when <TT>backuplocation</TT> is set to <CODE>central</CODE>. It is checked <EM>after</EM> the <TT>UNISONBACKUPDIR</TT> environment variable.<BR>
<BR>
<DT CLASS="dt-description"><B>backuplocation <TT>xxx</TT></B><DD CLASS="dd-description">
This preference determines whether backups should be kept locally, near the original files, or in a central directory specified by the <TT>backupdir</TT> preference. If set to <CODE>local</CODE>, backups will be kept in the same directory as the original files, and if set to <CODE>central</CODE>, <TT>backupdir</TT> will be used instead.<BR>
<BR>
<DT CLASS="dt-description"><B>backupnot <TT>xxx</TT></B><DD CLASS="dd-description">
The values of this preference specify paths or individual files or regular expressions that should <EM>not</EM> be backed up, even if the <TT>backup</TT> preference selects them&mdash;i.e., it selectively overrides <TT>backup</TT>. The same caveats apply here as with <TT>ignore</TT> and t ignorenot.<BR>
<BR>
<DT CLASS="dt-description"><B>backupprefix <TT>xxx</TT></B><DD CLASS="dd-description">
When a backup for a file <CODE>NAME</CODE> is created, it is stored in a directory specified by <TT>backuplocation</TT>, in a file called <TT>backupprefix</TT><CODE>NAME</CODE><TT>backupsuffix</TT>. <TT>backupprefix</TT> can include a directory name (causing Unison to keep all backup files for a given directory in a subdirectory with this name), and both <TT>backupprefix</TT> and <TT>backupsuffix</TT> can contain the string<TT><I>$VERSION</I></TT>, which will be replaced by the <EM>age</EM> of the backup (1 for the most recent, 2 for the second most recent, and so on...). This keyword is ignored if it appears in a directory name in the prefix; if it does not appear anywhere in the prefix or the suffix, it will be automatically placed at the beginning of the suffix.<BR>
<BR>
<DT CLASS="dt-description"><B>backups </B><DD CLASS="dd-description">
Setting this flag to true is equivalent to setting <TT>backuplocation</TT> to <TT>local</TT> and <TT>backup</TT> to <CODE>Name *</CODE>.<BR>
<BR>
<DT CLASS="dt-description"><B>backupsuffix <TT>xxx</TT></B><DD CLASS="dd-description">
See <TT>backupprefix</TT> for full documentation.<BR>
<BR>
<DT CLASS="dt-description"><B>batch </B><DD CLASS="dd-description">
When this is set to <TT>true</TT>, the user interface will ask no questions at all. Non-conflicting changes will be propagated; conflicts will be skipped.<BR>
<BR>
<DT CLASS="dt-description"><B>confirmmerge </B><DD CLASS="dd-description">
Setting this preference causes both the text and graphical interfaces to ask the user if the results of a merge command may be commited to the replica or not. Since the merge command works on temporary files, the user can then cancel all the effects of applying the merge if it turns out that the result is not satisfactory. In batch-mode, this preference has no effect.<BR>
<BR>
<DT CLASS="dt-description"><B>contactquietly </B><DD CLASS="dd-description">
If this flag is set, Unison will skip displaying the `Contacting server' window (which some users find annoying) during startup.<BR>
<BR>
<DT CLASS="dt-description"><B>debug <TT>xxx</TT></B><DD CLASS="dd-description">
This preference is used to make Unison print various sorts of information about what it is doing internally on the standard error stream. It can be used many times, each time with the name of a module for which debugging information should be printed. Possible arguments for <CODE>debug</CODE> can be found by looking for calls to <CODE>Util.debug</CODE> in the sources (using, e.g., <CODE>grep</CODE>). Setting <CODE>-debug all</CODE> causes information from <EM>all</EM> modules to be printed (this mode of usage is the first one to try, if you are trying to understand something that Unison seems to be doing wrong); <CODE>-debug verbose</CODE> turns on some additional debugging output from some modules (e.g., it will show exactly what bytes are being sent across the network).<BR>
<BR>
<DT CLASS="dt-description"><B>diff <TT>xxx</TT></B><DD CLASS="dd-description">
This preference can be used to control the name and command-line arguments of the system utility used to generate displays of file differences. The default is `<CODE>diff -u</CODE>'. If the value of this preference contains the substrings CURRENT1 and CURRENT2, these will be replaced by the names of the files to be diffed. If not, the two filenames will be appended to the command. In both cases, the filenames are suitably quoted.<BR>
<BR>
<DT CLASS="dt-description"><B>doc <TT>xxx</TT></B><DD CLASS="dd-description">
The command-line argument <TT>-doc <I>secname</I></TT> causes unison to display section <TT><I>secname</I></TT> of the manual on the standard output and then exit. Use <CODE>-doc all</CODE> to display the whole manual, which includes exactly the same information as the printed and HTML manuals, modulo formatting. Use <CODE>-doc topics</CODE> to obtain a list of the names of the various sections that can be printed.<BR>
<BR>
<DT CLASS="dt-description"><B>dumbtty </B><DD CLASS="dd-description">
When set to <CODE>true</CODE>, this flag makes the text mode user interface avoid trying to change any of the terminal settings. (Normally, Unison puts the terminal in `raw mode', so that it can do things like overwriting the current line.) This is useful, for example, when Unison runs in a shell inside of Emacs. <BR>
<BR>
When <CODE>dumbtty</CODE> is set, commands to the user interface need to be followed by a carriage return before Unison will execute them. (When it is off, Unison recognizes keystrokes as soon as they are typed.)<BR>
<BR>
This preference has no effect on the graphical user interface.<BR>
<BR>
<DT CLASS="dt-description"><B>dumparchives </B><DD CLASS="dd-description">
When this preference is set, Unison will create a file unison.dump on each host, containing a text summary of the archive, immediately after loading it.<BR>
<BR>
<DT CLASS="dt-description"><B>fastcheck <TT>xxx</TT></B><DD CLASS="dd-description">
When this preference is set to <CODE>true</CODE>, Unison will use file creation times as `pseudo inode numbers' when scanning replicas for updates, instead of reading the full contents of every file. Under Windows, this may cause Unison to miss propagating an update if the create time, modification time, and length of the file are all unchanged by the update (this is not easy to achieve, but it can be done). However, Unison will never <EM>overwrite</EM> such an update with a change from the other replica, since it always does a safe check for updates just before propagating a change. Thus, it is reasonable to use this switch under Windows most of the time and occasionally run Unison once with <TT>fastcheck</TT> set to <CODE>false</CODE>, if you are worried that Unison may have overlooked an update. The default value of the preference is <CODE>auto</CODE>, which causes Unison to use fast checking on Unix replicas (where it is safe) and slow checking on Windows replicas. For backward compatibility, <CODE>yes</CODE>, <CODE>no</CODE>, and <CODE>default</CODE> can be used in place of <CODE>true</CODE>, <CODE>false</CODE>, and <CODE>auto</CODE>. See the <A HREF="#fastcheck">Fast Checking</A> section for more information.<BR>
<BR>
<DT CLASS="dt-description"><B>follow <TT>xxx</TT></B><DD CLASS="dd-description">
Including the preference <TT>-follow <I>pathspec</I></TT> causes Unison to treat symbolic links matching <TT><I>pathspec</I></TT> as `invisible' and behave as if the object pointed to by the link had appeared literally at this position in the replica. See the <A HREF="#symlinks">Symbolic Links</A> section for more details. The syntax of <TT><I>pathspec&gt;</I></TT> is described in the <A HREF="#pathspec">Path Specification</A> section.<BR>
<BR>
<DT CLASS="dt-description"><B>force <TT>xxx</TT></B><DD CLASS="dd-description">
Including the preference <TT>-force <I>root</I></TT> causes Unison to resolve all differences (even non-conflicting changes) in favor of <TT><I>root</I></TT>. This effectively changes Unison from a synchronizer into a mirroring utility. <BR>
<BR>
You can also specify <CODE>-force newer</CODE> (or <CODE>-force older</CODE>) to force Unison to choose the file with the later (earlier) modtime. In this case, the <CODE>-times</CODE> preference must also be enabled.<BR>
<BR>
This preference should be used only if you are <EM>sure</EM> you know what you are doing!<BR>
<BR>
<DT CLASS="dt-description"><B>group </B><DD CLASS="dd-description">
When this flag is set to <CODE>true</CODE>, the group attributes of the files are synchronized. Whether the group names or the group identifiers are synchronizeddepends on the preference <TT>numerids</TT>.<BR>
<BR>
<DT CLASS="dt-description"><B>height <TT>n </TT></B><DD CLASS="dd-description">
Used to set the height (in lines) of the main window in the graphical user interface.<BR>
<BR>
<DT CLASS="dt-description"><B>ignore <TT>xxx</TT></B><DD CLASS="dd-description">
Including the preference <TT>-ignore <I>pathspec</I></TT> causes Unison to completely ignore paths that match <TT><I>pathspec</I></TT> (as well as their children). This is useful for avoiding synchronizing temporary files, object files, etc. The syntax of <TT><I>pathspec</I></TT> is described in the <A HREF="#pathspec">Path Specification</A> section, and further details on ignoring paths is found in the <A HREF="#ignore">Ignoring Paths</A> section.<BR>
<BR>
<DT CLASS="dt-description"><B>ignorecase <TT>xxx</TT></B><DD CLASS="dd-description">
When set to <TT>true</TT>, this flag causes Unison to treat filenames as case insensitive&mdash;i.e., files in the two replicas whose names differ in (upper- and lower-case) `spelling' are treated as the same file. When the flag is set to <TT>false</TT>, Unison will treat all filenames as case sensitive. Ordinarily, when the flag is set to t default, filenames are automatically taken to be case-insensitive if either host is running Windows or OSX. In rare circumstances it is useful to set the flag manually (e.g. when running Unison on a Unix system with a FAT [Windows] volume mounted).<BR>
<BR>
<DT CLASS="dt-description"><B>ignorelocks </B><DD CLASS="dd-description">
When this preference is set, Unison will ignore any lock files that may have been left over from a previous run of Unison that was interrupted while reading or writing archive files; by default, when Unison sees these lock files it will stop and request manualintervention. This option should be set only if you are <EM>positive</EM> that no other instance of Unison might be concurrently accessing the same archive files (e.g., because there was only one instance of unison running and it has just crashed or you have just killed it). It is probably not a good idea to set this option in a profile: it is intended for command-line use.<BR>
<BR>
<DT CLASS="dt-description"><B>ignorenot <TT>xxx</TT></B><DD CLASS="dd-description">
This preference overrides the preference <TT>ignore</TT>.
It gives a list of patterns
(in the same format as
<CODE>ignore</CODE>) for paths that should definitely <EM>not</EM> be ignored,
whether or not they happen to match one of the <CODE>ignore</CODE> patterns.
<BR>
<BR>
Note that the semantics of <TT>ignore</TT> and <TT>ignorenot</TT> is a
little counter-intuitive. When detecting updates, Unison examines
paths in depth-first order, starting from the roots of the replicas
and working downwards. Before examining each path, it checks whether
it matches <TT>ignore</TT> and does not match <TT>ignorenot</TT>; in this case
it skips this path <EM>and all its descendants</EM>. This means that,
if some parent of a given path matches an <TT>ignore</TT> pattern, then
it will be skipped even if the path itself matches an <TT>ignorenot</TT>
pattern. In particular, putting <TT>ignore = Path *</TT> in your profile
and then using t ignorenot to select particular paths to be
synchronized will not work. Instead, you should use the <TT>path</TT>
preference to choose particular paths to synchronize.<BR>
<BR>
<DT CLASS="dt-description"><B>immutable <TT>xxx</TT></B><DD CLASS="dd-description">
This preference specifies paths for directories whose children are all immutable files &mdash; i.e., once a file has been created, its contents never changes. When scanning for updates, Unison does not check whether these files have been modified; this can speed update detection significantly (in particular, for mail directories).<BR>
<BR>
<DT CLASS="dt-description"><B>immutablenot <TT>xxx</TT></B><DD CLASS="dd-description">
This preference overrides <TT>immutable</TT>.<BR>
<BR>
<DT CLASS="dt-description"><B>key <TT>xxx</TT></B><DD CLASS="dd-description">
Used in a profile to define a numeric key (0-9) that can be used in the graphical user interface to switch immediately to this profile.<BR>
<BR>
<DT CLASS="dt-description"><B>killserver </B><DD CLASS="dd-description">
When set to <CODE>true</CODE>, this flag causes Unison to kill the remote server process when the synchronization is finished. This behavior is the default for <CODE>ssh</CODE> connections, so this preference is not normally needed when running over <CODE>ssh</CODE>; it is provided so that socket-mode servers can be killed off after a single run of Unison, rather than waiting to accept future connections. (Some users prefer to start a remote socket server for each run of Unison, rather than leaving one running all the time.)<BR>
<BR>
<DT CLASS="dt-description"><B>label <TT>xxx</TT></B><DD CLASS="dd-description">
Used in a profile to provide a descriptive string documenting its settings. (This is useful for users that switch between several profiles, especially using the `fast switch' feature of the graphical user interface.)<BR>
<BR>
<DT CLASS="dt-description"><B>log </B><DD CLASS="dd-description">
When this flag is set, Unison will log all changes to the filesystems
on a file.<BR>
<BR>
<DT CLASS="dt-description"><B>logfile <TT>xxx</TT></B><DD CLASS="dd-description">
By default, logging messages will be appended to the file
<CODE>unison.log</CODE> in your HOME directory. Set this preference if
you prefer another file.<BR>
<BR>
<DT CLASS="dt-description"><B>maxbackups <TT>n </TT></B><DD CLASS="dd-description">
This preference specifies the number of backup versions that will be kept by unison, for each path that matches the predicate <CODE>backup</CODE>. The default is 2.<BR>
<BR>
<DT CLASS="dt-description"><B>maxthreads <TT>n </TT></B><DD CLASS="dd-description">
This preference controls how much concurrency is allowed during the transport phase. Normally, it should be set reasonably high (default is 20) to maximize performance, but when Unison is used over a low-bandwidth link it may be helpful to set it lower (e.g. to 1) so that Unison doesn't soak up all the available bandwidth.<BR>
<BR>
<DT CLASS="dt-description"><B>merge <TT>xxx</TT></B><DD CLASS="dd-description">
This preference can be used to run a merge program which will create a new version for each of the files and the backup, with the last backup and the both replicas. Setting the <TT>merge</TT> preference for a path will also cause this path to be backed up, just like t backup. The syntax of <TT><I>pathspec&gt;cmd</I></TT> is described in the <A HREF="#pathspec">Path Specification</A> section, and further details on Merging functions are present in the <A HREF="#merge">Merging files</A> section.<BR>
<BR>
<DT CLASS="dt-description"><B>mergebatch <TT>xxx</TT></B><DD CLASS="dd-description">
Normally, when Unison is run with the <TT>batch</TT> flag set to true, it does not invoke any external merge programs. To tell it that a given file can be merged even when in batch mode, use the <TT>mergebatch</TT> preference instead of <TT>merge</TT>. When running in non-batch mode, the <TT>merge</TT> preference is used instead of <TT>mergebatch</TT> if both are specified for a given path.<BR>
<BR>
<DT CLASS="dt-description"><B>numericids </B><DD CLASS="dd-description">
When this flag is set to <CODE>true</CODE>, groups and users are synchronized numerically, rather than by name. <BR>
<BR>
The special uid 0 and the special group 0 are never mapped via user/group names even if this preference is not set.<BR>
<BR>
<DT CLASS="dt-description"><B>owner </B><DD CLASS="dd-description">
When this flag is set to <CODE>true</CODE>, the owner attributes of the files are synchronized. Whether the owner names or the owner identifiers are synchronizeddepends on the preference extttnumerids.<BR>
<BR>
<DT CLASS="dt-description"><B>path <TT>xxx</TT></B><DD CLASS="dd-description">
When no <CODE>path</CODE> preference is given, Unison will simply synchronize the two entire replicas, beginning from the given pair of roots. If one or more <CODE>path</CODE> preferences are given, then Unison will synchronize only these paths and their children. (This is useful for doing a fast sync of just one directory, for example.) Note that <TT>path</TT> preferences are intepreted literally&mdash;they are not regular expressions.<BR>
<BR>
<DT CLASS="dt-description"><B>perms <TT>n </TT></B><DD CLASS="dd-description">
The integer value of this preference is a mask indicating which permission bits should be synchronized. It is set by default to 0<I>o</I>1777: all bits but the set-uid and set-gid bits are synchronised (synchronizing theses latter bits can be a security hazard). If you want to synchronize all bits, you can set the value of this preference to &minus;1.<BR>
<BR>
<DT CLASS="dt-description"><B>prefer <TT>xxx</TT></B><DD CLASS="dd-description">
Including the preference <TT>-prefer <I>root</I></TT> causes Unison always to resolve conflicts in favor of <TT><I>root</I></TT>, rather than asking for guidance from the user. (The syntax of <TT><I>root</I></TT> is the same as for the <CODE>root</CODE> preference, plus the special values <CODE>newer</CODE> and <CODE>older</CODE>.) <BR>
<BR>
This preference should be used only if you are <EM>sure</EM> you know what you are doing!<BR>
<BR>
<DT CLASS="dt-description"><B>pretendwin </B><DD CLASS="dd-description">
When set to true, this preference makes Unison use Windows-style fast update detection (using file creation times as &#8220;pseudo-inode-numbers&#8221;), even when running on a Unix system. This switch should be used with care, as it is less safe than the standard update detection method, but it can be useful for synchronizing VFAT filesystems (which do not support inode numbers) mounted on Unix systems. The <TT>fastcheck</TT> option should also be set to true.<BR>
<BR>
<DT CLASS="dt-description"><B>repeat <TT>xxx</TT></B><DD CLASS="dd-description">
Setting this preference causes the text-mode interface to synchronize repeatedly, rather than doing it just once and stopping. If the argument is a number, Unison will pause for that many seconds before beginning again. If the argument is a path, Unison will wait for the file at this path&mdash;called a <EM>changelog</EM>&mdash;to be modified (on either the client or the server machine), read the contents of the changelog (which should be a newline-separated list of paths) on both client and server, combine the results, and start again, using the list of paths read from the changelogs as the '-path' preference for the new run. The idea is that an external process will watch the filesystem and, when it thinks something may have changed, write the changed pathname to its local changelog where Unison will find it the next time it looks. If the changelogs have not been modified, Unison will wait, checking them again every few seconds.<BR>
<BR>
<DT CLASS="dt-description"><B>retry <TT>n </TT></B><DD CLASS="dd-description">
Setting this preference causes the text-mode interface to try again to synchronize updated paths where synchronization fails. Each such path will be tried N times.<BR>
<BR>
<DT CLASS="dt-description"><B>root <TT>xxx</TT></B><DD CLASS="dd-description">
Each use of this preference names the root of one of the replicas for Unison to synchronize. Exactly two roots are needed, so normal modes of usage are either to give two values for <CODE>root</CODE> in the profile, or to give no values in the profile and provide two on the command line. Details of the syntax of roots can be found in the <A HREF="#roots">Roots</A> section.<BR>
<BR>
The two roots can be given in either order; Unison will sort them into a canonical order before doing anything else. It also tries to `canonize' the machine names and paths that appear in the roots, so that, if Unison is invoked later with a slightly different name for the same root, it will be able to locate the correct archives.<BR>
<BR>
<DT CLASS="dt-description"><B>rootalias <TT>xxx</TT></B><DD CLASS="dd-description">
When calculating the name of the archive files for a given pair of roots, Unison replaces any roots matching the left-hand side of any rootalias rule by the corresponding right-hand side.<BR>
<BR>
<DT CLASS="dt-description"><B>rshargs <TT>xxx</TT></B><DD CLASS="dd-description">
The string value of this preference will be passed as additional arguments (besides the host name and the name of the Unison executable on the remote system) to the <CODE>rsh</CODE> command used to invoke the remote server. <BR>
<BR>
<DT CLASS="dt-description"><B>rshcmd <TT>xxx</TT></B><DD CLASS="dd-description">
This preference can be used to explicitly set the name of the rsh executable (e.g., giving a full path name), if necessary.<BR>
<BR>
<DT CLASS="dt-description"><B>rsrc <TT>xxx</TT></B><DD CLASS="dd-description">
When set to <TT>true</TT>, this flag causes Unison to synchronize resource forks and HFS meta-data. On filesystems that do not natively support resource forks, this data is stored in Carbon-compatible ._ AppleDouble files. When the flag is set to <TT>false</TT>, Unison will not synchronize these data. Ordinarily, the flag is set to <TT>default</TT>, and these data are
automatically synchronized if either host is running OSX. In rare circumstances it is useful to set the flag manually.<BR>
<BR>
<DT CLASS="dt-description"><B>rsync </B><DD CLASS="dd-description">
Unison uses the 'rsync algorithm' for 'diffs-only' transfer of updates to large files. Setting this flag to false makes Unison use whole-file transfers instead. Under normal circumstances, there is no reason to do this, but if you are having trouble with repeated 'rsync failure' errors, setting it to false should permit you to synchronize the offending files.<BR>
<BR>
<DT CLASS="dt-description"><B>servercmd <TT>xxx</TT></B><DD CLASS="dd-description">
This preference can be used to explicitly set the name of the Unison executable on the remote server (e.g., giving a full path name), if necessary.<BR>
<BR>
<DT CLASS="dt-description"><B>showarchive </B><DD CLASS="dd-description">
When this preference is set, Unison will print out the 'true names'of the roots, in the same form as is expected by the <TT>rootalias</TT>preference.<BR>
<BR>
<DT CLASS="dt-description"><B>silent </B><DD CLASS="dd-description">
When this preference is set to <TT>true</TT>, the textual user interface will print nothing at all, except in the case of errors. Setting <TT>silent</TT> to true automatically sets the <TT>batch</TT> preference to <TT>true</TT>.<BR>
<BR>
<DT CLASS="dt-description"><B>sortbysize </B><DD CLASS="dd-description">
When this flag is set, the user interface will list changed files by size (smallest first) rather than by name. This is useful, for example, for synchronizing over slow links, since it puts very large files at the end of the list where they will not prevent smaller files from being transferred quickly.<BR>
<BR>
This preference (as well as the other sorting flags, but not the sorting preferences that require patterns as arguments) can be set interactively and temporarily using the 'Sort' menu in the graphical user interface.<BR>
<BR>
<DT CLASS="dt-description"><B>sortfirst <TT>xxx</TT></B><DD CLASS="dd-description">
Each argument to <TT>sortfirst</TT> is a pattern <TT><I>pathspec</I></TT>, which describes a set of paths. Files matching any of these patterns will be listed first in the user interface. The syntax of <TT><I>pathspec</I></TT> is described in the <A HREF="#pathspec">Path Specification</A> section.<BR>
<BR>
<DT CLASS="dt-description"><B>sortlast <TT>xxx</TT></B><DD CLASS="dd-description">
Similar to <CODE>sortfirst</CODE>, except that files matching one of these patterns will be listed at the very end.<BR>
<BR>
<DT CLASS="dt-description"><B>sortnewfirst </B><DD CLASS="dd-description">
When this flag is set, the user interface will list newly created files before all others. This is useful, for example, for checking that newly created files are not `junk', i.e., ones that should be ignored or deleted rather than synchronized.<BR>
<BR>
<DT CLASS="dt-description"><B>sshargs <TT>xxx</TT></B><DD CLASS="dd-description">
The string value of this preference will be passed as additional arguments (besides the host name and the name of the Unison executable on the remote system) to the <CODE>ssh</CODE> command used to invoke the remote server. <BR>
<BR>
<DT CLASS="dt-description"><B>sshcmd <TT>xxx</TT></B><DD CLASS="dd-description">
This preference can be used to explicitly set the name of the ssh executable (e.g., giving a full path name), if necessary.<BR>
<BR>
<DT CLASS="dt-description"><B>sshversion <TT>xxx</TT></B><DD CLASS="dd-description">
This preference can be used to control which version of ssh should be used to connect to the server. Legal values are 1 and 2, which will cause unison to try to use <CODE>ssh1</CODE> or<CODE>ssh2</CODE> instead of just <CODE>ssh</CODE> to invoke ssh. The default value is empty, which will make unison use whatever version of ssh is installed as the default `ssh' command.<BR>
<BR>
<DT CLASS="dt-description"><B>terse </B><DD CLASS="dd-description">
When this preference is set to <TT>true</TT>, the user interface will not print status messages.<BR>
<BR>
<DT CLASS="dt-description"><B>testserver </B><DD CLASS="dd-description">
Setting this flag on the command line causes Unison to attempt to connect to the remote server and, if successful, print a message and immediately exit. Useful for debugging installation problems. Should not be set in preference files.<BR>
<BR>
<DT CLASS="dt-description"><B>times </B><DD CLASS="dd-description">
When this flag is set to <CODE>true</CODE>, file modification times (but not directory modtimes) are propagated.<BR>
<BR>
<DT CLASS="dt-description"><B>ui <TT>xxx</TT></B><DD CLASS="dd-description">
This preference selects either the graphical or the textual user interface. Legal values are <CODE>graphic</CODE> or <CODE>text</CODE>. <BR>
<BR>
Because this option is processed specially during Unison's start-up sequence, it can <EM>only</EM> be used on the command line. In preference files it has no effect.<BR>
<BR>
If the Unison executable was compiled with only a textual interface, this option has no effect. (The pre-compiled binaries are all compiled with both interfaces available.)<BR>
<BR>
<DT CLASS="dt-description"><B>version </B><DD CLASS="dd-description">
Print the current version number and exit. (This option only makes sense on the command line.)<BR>
<BR>
<DT CLASS="dt-description"><B>xferbycopying </B><DD CLASS="dd-description">
When this preference is set, Unison will try to avoid transferring file contents across the network by recognizing when a file with the required contents already exists in the target replica. This usually allows file moves to be propagated very quickly. The default value is<TT>true</TT>. </DL>
<!--TOC subsection Profiles-->
<H3 CLASS="subsection"><A NAME="profile"></A>Profiles</H3><!--SEC END -->
A <EM>profile</EM> is a text file that specifies permanent settings for
roots, paths, ignore patterns, and other preferences, so that they do
not need to be typed at the command line every time Unison is run.
Profiles should reside in the <CODE>.unison</CODE> directory on the client
machine. If Unison is started with just one argument <TT><I>name</I></TT> on
the command line, it looks for a profile called <TT><I>name</I></TT><TT>.prf</TT> in
the <CODE>.unison</CODE> directory. If it is started with no arguments, it
scans the <CODE>.unison</CODE> directory for files whose names end in
<CODE>.prf</CODE> and offers a menu (provided that the Unison executable is compiled with the graphical user interface). If a file named <CODE>default.prf</CODE> is
found, its settings will be offered as the default choices.<BR>
<BR>
To set the value of a preference <TT>p</TT> permanently, add to the
appropriate profile a line of the form
<PRE CLASS="verbatim">
p = true
</PRE>for a boolean flag or
<PRE CLASS="verbatim">
p = &lt;value&gt;
</PRE>for a preference of any other type. <BR>
<BR>
Whitespaces around <TT>p</TT> and <TT>xxx</TT> are ignored.
A profile may also include blank lines and lines beginning
with <TT>#</TT>; both are ignored.<BR>
<BR>
When Unison starts, it first reads the profile and then the command
line, so command-line options will override settings from the
profile. <BR>
<BR>
Profiles may also include lines of the form <TT>include
<I>name</I></TT>, which will cause the file <TT><I>name</I></TT> (or
<TT><I>name</I></TT><TT>.prf</TT>, if <TT><I>name</I></TT> does not exist in the
<CODE>.unison</CODE> directory) to be read at the point, and included as if
its contents, instead of the <TT>include</TT> line, was part of the
profile. Include lines allows settings common to several profiles to
be stored in one place.<BR>
<BR>
A profile may include a preference `<TT>label = <I>desc</I></TT>' to
provide a description of the options selected in this profile. The
string <TT><I>desc</I></TT> is listed along with the profile name in the profile
selection dialog, and displayed in the top-right corner of the main
Unison window in the graphical user interface.<BR>
<BR>
The graphical user-interface also supports one-key shortcuts for commonly
used profiles. If a profile contains a preference of the form
`<TT>key = <I>n</I></TT>', where <TT><I>n</I></TT> is a single digit, then
pressing this digit key will cause Unison to immediately switch to
this profile and begin synchronization again from scratch. In this
case, all actions that have been selected for a set of changes
currently being displayed will be discarded.<BR>
<BR>
<!--TOC subsection Sample Profiles-->
<H3 CLASS="subsection"><A NAME="profileegs"></A>Sample Profiles</H3><!--SEC END -->
<!--TOC subsubsection A Minimal Profile-->
<H4 CLASS="subsubsection"><A NAME="minimalprofile"></A>A Minimal Profile</H4><!--SEC END -->
Here is a very minimal profile file, such as might be found in <TT>.unison/default.prf</TT>:
<PRE CLASS="verbatim">
# Roots of the synchronization
root = /home/bcpierce
root = ssh://saul//home/bcpierce
# Paths to synchronize
path = current
path = common
path = .netscape/bookmarks.html
</PRE>
<!--TOC subsubsection A Basic Profile-->
<H4 CLASS="subsubsection"><A NAME="basicprofile"></A>A Basic Profile</H4><!--SEC END -->
Here is a more sophisticated profile, illustrating some other useful
features.
<PRE CLASS="verbatim">
# Roots of the synchronization
root = /home/bcpierce
root = ssh://saul//home/bcpierce
# Paths to synchronize
path = current
path = common
path = .netscape/bookmarks.html
# Some regexps specifying names and paths to ignore
ignore = Name temp.*
ignore = Name *~
ignore = Name .*~
ignore = Path */pilot/backup/Archive_*
ignore = Name *.o
ignore = Name *.tmp
# Window height
height = 37
# Keep a backup copy of every file in a central location
backuplocation = central
backupdir = /home/bcpierce/backups
backup = Name *
backupprefix = $VERSION.
backupsuffix =
# Use this command for displaying diffs
diff = diff -y -W 79 --suppress-common-lines
# Log actions to the terminal
log = true
</PRE>
<!--TOC subsubsection A Power-User Profile-->
<H4 CLASS="subsubsection"><A NAME="powerprofile"></A>A Power-User Profile</H4><!--SEC END -->
When Unison is used with large replicas, it is often convenient to be
able to synchronize just a part of the replicas on a given run (this
saves the time of detecting updates in the other parts). This can be
accomplished by splitting up the profile into several parts &mdash; a common
part containing most of the preference settings, plus one &#8220;top-level&#8221;
file for each set of paths that need to be synchronized. (The <TT>include</TT> mechanism can also be used to allow the same set of preference
settings to be used with different roots.)<BR>
<BR>
The collection
of profiles implementing this scheme might look as follows.
The file <TT>default.prf</TT> is empty except for an <TT>include</TT>
directive:
<PRE CLASS="verbatim">
# Include the contents of the file common
include common
</PRE>Note that the name of the common file is <TT>common</TT>, not <TT>common.prf</TT>; this prevents Unison from offering <TT>common</TT> as one of
the list of profiles in the opening dialog (in the graphical UI).<BR>
<BR>
The file <TT>common</TT> contains the real preferences:
<PRE CLASS="verbatim">
# Roots of the synchronization
root = /home/bcpierce
root = ssh://saul//home/bcpierce
# (... other preferences ...)
# If any new preferences are added by Unison (e.g. 'ignore'
# preferences added via the graphical UI), then store them in the
# file 'common' rathen than in the top-level preference file
addprefsto = common
# regexps specifying names and paths to ignore
ignore = Name temp.*
ignore = Name *~
ignore = Name .*~
ignore = Path */pilot/backup/Archive_*
ignore = Name *.o
ignore = Name *.tmp
</PRE>Note that there are no <TT>path</TT> preferences in <TT>common</TT>. This
means that, when we invoke Unison with the default profile (e.g., by
typing '<TT>unison default</TT>' or just '<TT>unison</TT>' on the command
line), the whole replicas will be synchronized. (If we <EM>never</EM> want
to synchronize the whole replicas, then <TT>default.prf</TT> would instead
include settings for all the paths that are usually synchronized.)<BR>
<BR>
To synchronize just part of the replicas, Unison is invoked with an
alternate preference file&mdash;e.g., doing '<TT>unison workingset</TT>', where the
preference file <TT>workingset.prf</TT> contains
<PRE CLASS="verbatim">
path = current/papers
path = Mail/inbox
path = Mail/drafts
include common
</PRE>causes Unison to synchronize just the subdirectories <TT>current/papers</TT>
and <TT>older/papers</TT>.<BR>
<BR>
The <TT>key</TT> preference can be used in combination with the graphical UI
to quickly switch between different sets of paths. For example, if the
file <TT>mail.prf</TT> contains
<PRE CLASS="verbatim">
path = Mail
batch = true
key = 2
include common
</PRE>then pressing 2 will cause Unison to look for updates in the <TT>Mail</TT>
subdirectory and (because the <TT>batch</TT> flag is set) immediately
propagate any that it finds.<BR>
<BR>
<!--TOC subsection Keeping Backups-->
<H3 CLASS="subsection"><A NAME="backups"></A>Keeping Backups</H3><!--SEC END -->
When Unison overwrites a file or directory by propagating a new version from
the other replica, it can keep the old version around as a backup. There
are several preferences that control precisely where these backups are
stored and how they are named.<BR>
<BR>
To enable backups, you must give one or more <CODE>backup</CODE> preferences.
Each of these has the form
<PRE CLASS="verbatim">
backup = &lt;pathspec&gt;
</PRE>where <CODE>&lt;pathspec&gt;</CODE> has the same form as for the <CODE>ignore</CODE>
preference. For example,
<PRE CLASS="verbatim">
backup = Name *
</PRE>causes Unison to keep backups of <EM>all</EM> files and directories. The
<CODE>backupnot</CODE> preference can be used to give a few exceptions: it
specifies which files and directories should <EM>not</EM> be backed up, even if
they match the <CODE>backup</CODE> pathspec. <BR>
<BR>
It is important to note that the <CODE>pathspec</CODE> is matched against the path
that is being updated by Unison, not its descendants. For example, if you
set <CODE>backup = Name *.txt</CODE> and then delete a whole directory named
<CODE>foo</CODE> containing some text files, these files will not be backed up
because Unison will just check that <CODE>foo</CODE> does not match <CODE>*.txt</CODE>.
Similarly, if the directory itself happened to be called <CODE>foo.txt</CODE>,
then the whole directory and all the files in it will be backed up,
regardless of their names. <BR>
<BR>
Backup files can be stored either <EM>centrally</EM> or <EM>locally</EM>. This
behavior is controlled by the preference <CODE>backuplocation</CODE>, whose value
must be either <CODE>central</CODE> or <CODE>local</CODE>. (The default is
<CODE>central</CODE>.) <BR>
<BR>
When backups are stored locally, they are kept in the same
directory as the original.<BR>
<BR>
When backups are stored centrally, the directory used to hold them is
controlled by the preference <CODE>backupdir</CODE> and the
environment variable <CODE>UNISONBACKUPDIR</CODE>. (The environment variable is
checked first.) If neither of these are set, then the directory
<CODE>.unison/backup</CODE> in the user's home directory is used.<BR>
<BR>
The preference <CODE>backupversions</CODE> controls how many previous versions of
each file are kept. The default is 2.<BR>
<BR>
By default, backup files are named <CODE>.unison.FILENAME.VERSION.bak</CODE>,
where <CODE>FILENAME</CODE> is the original filename and <CODE>version</CODE> is the
backup number (001 for the most recent, 002 for the next most recent,
etc.). This can be changed by setting the preferences <CODE>backupprefix</CODE>
and/or <CODE>backupsuffix</CODE>. If desired, <CODE>backupprefix</CODE> may include a
directory prefix; this can be used with <CODE>backuplocation = local</CODE> to put all
backup files for each directory into a single subdirectory. For example, setting
<PRE CLASS="verbatim">
backuplocation = local
backupprefix = .unison/$VERSION.
backupsuffix =
</PRE>will put all backups in a local subdirectory named <CODE>.unison</CODE>. Also,
note that the string <CODE>$VERSION</CODE> in either <CODE>backupprefix</CODE> or
<CODE>backupsuffix</CODE> (it must appear in one or the other) is replaced by
the version number. This can be used, for example, to ensure that backup
files retain the same extension as the originals.<BR>
<BR>
For backward compatibility, the <CODE>backups</CODE> preference is also supported.
It simply means <CODE>backup = Name *</CODE> and <CODE>backuplocation = local</CODE>.<BR>
<BR>
<!--TOC subsection Merging Conflicting Versions-->
<H3 CLASS="subsection"><A NAME="merge"></A>Merging Conflicting Versions</H3><!--SEC END -->
Unison can invoke external programs to merge conflicting versions of a file.
The preference <CODE>merge</CODE> controls this process. <BR>
<BR>
The <CODE>merge</CODE> preference may be given once or several times in a
preference file (it can also be given on the command line, of course, but
this tends to be awkward because of the spaces and special characters
involved). Each instance of the preference looks like this:
<PRE CLASS="verbatim">
merge = &lt;PATHSPEC&gt; -&gt; &lt;MERGECMD&gt;
</PRE>The <CODE>&lt;PATHSPEC&gt;</CODE> here has exactly the same format as for the
<CODE>ignore</CODE> preference (see the <A HREF="#pathspec">Path specification</A> section). For example,
using &#8220;<CODE>Name *.txt</CODE>&#8221; as the <CODE>&lt;PATHSPEC&gt;</CODE> tells Unison that this
command should be used whenever a file with extension <CODE>.txt</CODE> needs to
be merged. <BR>
<BR>
Many external merging programs require as inputs not just the two files that
need to be merged, but also a file containing the <EM>last synchronized
version</EM>. You can ask Unison to keep a copy of the last synchronized
version for some files using the <CODE>backupcurrent</CODE> preference. This
preference is used in exactly the same way as <CODE>backup</CODE> and its meaning
is similar, except that it causes backups to be kept of the <EM>current</EM>
contents of each file after it has been synchronized by Unison, rather than
the <EM>previous</EM> contents that Unison overwrote. These backups are kept
on <EM>both</EM> replicas in the same place as ordinary backup files&mdash;i.e.
according to the <CODE>backuplocation</CODE> and <CODE>backupdir</CODE> preferences.
They are named like the original files if <CODE>backupslocation</CODE> is set to
'central' and otherwise, Unison uses the <CODE>backupprefix</CODE> and
<CODE>backupsuffix</CODE> preferences and assumes a version number 000 for these
backups.<BR>
<BR>
The <CODE>&lt;MERGECMD&gt;</CODE> part of the preference specifies what external command
should be invoked to merge files at paths matching the <CODE>&lt;PATHSPEC&gt;</CODE>.
Within this string, several special substrings are recognized; these will be
substituted with appropriate values before invoking a sub-shell to execute
the command.
<UL CLASS="itemize"><LI CLASS="li-itemize">
<CODE>CURRENT1</CODE> is replaced by the name of (a temporary copy of)
the local variant of the file.
<LI CLASS="li-itemize"><CODE>CURRENT2</CODE> is replaced by the name of a temporary
file, into which the contents of the remote variant of the file have
been transferred by Unison prior to performing the merge.
<LI CLASS="li-itemize"><CODE>CURRENTARCH</CODE> is replaced by the name of the backed up copy
of the original version of the file (i.e., the file saved by Unison
if the current filename matches the path specifications for the
<CODE>backupcurrent</CODE> preference, as explained above), if one exists.
If no archive exists and <CODE>CURRENTARCH</CODE> appears in the
merge command, then an error is signalled.
<LI CLASS="li-itemize"><CODE>CURRENTARCHOPT</CODE> is replaced by the name of the backed up copy
of the original version of the file (i.e., its state at the end of
the last successful run of Unison), if one exists, or the empty
string if no archive exists.
<LI CLASS="li-itemize"><CODE>NEW</CODE> is replaced by the name of a temporary file
that Unison expects to be written by the merge program when it
finishes, giving the desired new contents of the file.
<LI CLASS="li-itemize"><CODE>PATH</CODE> is replaced by the path (relative to the roots of
the replicas) of the file being merged.
<LI CLASS="li-itemize"><CODE>NEW1</CODE> and <CODE>NEW2</CODE> are replaced by the names of temporary files
that Unison expects to be written by the merge program when it
is only able to partially merge the originals; in this case, <CODE>NEW1</CODE>
will be written back to the local replica and <CODE>NEW2</CODE> to the remote
replica; <CODE>NEWARCH</CODE>, if present, will be used as the &#8220;last common
state&#8221; of the replicas. (These three options are provided for
later compatibility with the Harmony data synchronizer.)
</UL>
To accomodate the wide variety of programs that users might want to use for
merging, Unison checks for several possible situations when the merge
program exits:
<UL CLASS="itemize"><LI CLASS="li-itemize">
If the merge program exits with a non-zero status, then merge is
considered to have failed and the replicas are not changed.
<LI CLASS="li-itemize">If the file <CODE>NEW</CODE> has been created, it is written back to both
replicas (and stored in the backup directory). Similarly, if just the
file <CODE>NEW1</CODE> has been created, it is written back to both
replicas.
<LI CLASS="li-itemize">If neither <CODE>NEW</CODE> nor <CODE>NEW1</CODE> have been created, then Unison
examines the temporary files <CODE>CURRENT1</CODE> and <CODE>CURRENT2</CODE> that
were given as inputs to the merge program. If either has been changed (or
both have been changed in identical ways), then its new contents are written
back to both replicas. If either <CODE>CURRENT1</CODE> or <CODE>CURRENT2</CODE> has
been <EM>deleted</EM>, then the contents of the other are written back to
both replicas.
<LI CLASS="li-itemize">If the files <CODE>NEW1</CODE>, <CODE>NEW2</CODE>, and <CODE>NEWARCH</CODE> have all
been created, they are written back to the local replica, remote replica,
and backup directory, respectively. If the files <CODE>NEW1</CODE>, <CODE>NEW2</CODE> have
been created, but <CODE>NEWARCH</CODE> has not, then these files are written back to the
local replica and remote replica, respectively. Also, if <CODE>NEW1</CODE> and
<CODE>NEW2</CODE> have identical contents, then the same contents are stored as
a backup (if the <CODE>backupcurrent</CODE> preference is set for this path) to
reflect the fact that the path is currently in sync.
<LI CLASS="li-itemize">If <CODE>NEW1</CODE> and <CODE>NEW2</CODE> (resp. <CODE>CURRENT1</CODE> and
<CODE>CURRENT2</CODE>) are created (resp. overwritten) with different contents
but the merge command did not fail (i.e., it exited with status code 0),
then we copy <CODE>NEW1</CODE> (resp. <CODE>CURRENT1</CODE>) to the other replica and
to the archive. <BR>
<BR>
This behavior is a design choice made to handle the case where a merge
command only synchronizes some specific contents between two files,
skipping some irrelevant information (order between entries, for
instance). We assume that, if the merge command exits normally, then the
two resulting files are &#8220;as good as equal.&#8221; (The reason we copy one on
top of the other is to avoid Unison detecting that the files are unequal
the next time it is run and trying again to merge them when, in fact, the
merge program has already made them as similar as it is able to.)
</UL>
If the <CODE>confirmmerge</CODE> preference is set and Unison is not run in
batch mode, then Unison will always ask for confirmation before
actually committing the results of the merge to the replicas.<BR>
<BR>
A large number of external merging programs are available.
For example, on Unix systems setting the <CODE>merge</CODE> preference to
<PRE CLASS="verbatim">
merge = Name *.txt -&gt; diff3 CURRENT1 CURRENTARCH CURRENT2 -m &gt; NEW
</PRE>will tell Unison to use the external <CODE>diff3</CODE> program for merging.
Alternatively, users of <CODE>emacs</CODE> may find the following settings convenient:
<PRE CLASS="verbatim">
merge = Name *.txt -&gt; emacs -q --eval '(ediff-merge-files-with-ancestor
"CURRENT1" "CURRENT2" "CURRENTARCH" nil "NEW")'
</PRE>(These commands are displayed here on two lines to avoid running off the
edge of the page. In your preference file, each command should be written on a
single line.)
Users running Mac OS X (you may need the Developer Tools installed to get
the <TT>opendiff</TT> utility) may prefer
<PRE CLASS="verbatim">
merge = Name *.txt -&gt; opendiff CURRENT1 CURRENT2 -ancestor CURRENTARCH -merge NEW
</PRE>Here is a slightly more involved hack. The <TT>opendiff</TT> program can
operate either with or without an archive file. A merge command of this
form
<PRE CLASS="verbatim">
merge = Name *.txt -&gt;
if [ CURRENTARCHOPTx = x ];
then opendiff CURRENT1 CURRENT2 -merge NEW;
else opendiff CURRENT1 CURRENT2 -ancestor CURRENTARCHOPT -merge NEW;
fi
</PRE>(still all on one line in the preference file!) will test whether an archive
file exists and use the appropriate variant of the arguments to <TT>opendiff</TT>. <BR>
<BR>
Ordinarily, external merge programs are only invoked when Unison is <EM>not</EM> running in batch mode. To specify an external merge program that
should be used no matter the setting of the <TT>batch</TT> flag, use the <TT>mergebatch</TT> preference instead of <TT>merge</TT>.
<BLOCKQUOTE CLASS="quote">
<I>Please post suggestions for other useful values of the
</I><CODE><I>merge</I></CODE><I> preference to the <TT>unison-users</TT> mailing list&mdash;we'd like
to give several examples here.
</I></BLOCKQUOTE>
<!--TOC subsection The User Interface-->
<H3 CLASS="subsection"><A NAME="ui"></A>The User Interface</H3><!--SEC END -->
Both the textual and the graphical user interfaces are intended to be
mostly self-explanatory. Here are just a few tricks:
<UL CLASS="itemize"><LI CLASS="li-itemize">
By default, when running on Unix the textual user interface will
try to put the terminal into the &#8220;raw mode&#8221; so that it reads the input a
character at a time rather than a line at a time. (This means you can
type just the single keystroke &#8220;<CODE>&gt;</CODE>&#8221; to tell Unison to
propagate a file from left to right, rather than &#8220;<CODE>&gt;</CODE> Enter.&#8221;)<BR>
<BR>
There are some situations, though, where this will not work &mdash; for
example, when Unison is running in a shell window inside Emacs.
Setting the <CODE>dumbtty</CODE> preference will force Unison to leave the
terminal alone and process input a line at a time.
</UL>
<!--TOC subsection Exit code-->
<H3 CLASS="subsection"><A NAME="exit"></A>Exit code</H3><!--SEC END -->
When running in the textual mode, Unison returns an exit status, which
describes whether, and at which level, the synchronization was successful.
The exit status could be useful when Unison is invoked from a script.
Currently, there are four possible values for the exit status:
<UL CLASS="itemize"><LI CLASS="li-itemize">
0: successful synchronization; everything is up-to-date now.
<LI CLASS="li-itemize">1: some files were skipped, but all file transfers were successful.
<LI CLASS="li-itemize">2: non-fatal failures occurred during file transfer.
<LI CLASS="li-itemize">3: a fatal error occurred, or the execution was interrupted.
</UL>
The graphical interface does not return any useful information through the
exit status.<BR>
<BR>
<!--TOC subsection Path specification-->
<H3 CLASS="subsection"><A NAME="pathspec"></A>Path specification</H3><!--SEC END -->
Several Unison preferences (e.g., <CODE>ignore</CODE>/<CODE>ignorenot</CODE>,
<CODE>follow</CODE>, <CODE>sortfirst</CODE>/<CODE>sortlast</CODE>, <CODE>backup</CODE>,
<CODE>merge</CODE>, etc.)
specify individual paths or sets of paths. These preferences share a
common syntax based on regular-expressions. Each preference
is associated with a list of path patterns; the paths specified are those
that match any one of the path pattern.
<UL CLASS="itemize"><LI CLASS="li-itemize">
Pattern preferences can be given on the command line,
or, more often, stored in profiles, using the same syntax as other preferences.
For example, a profile line of the form
<PRE>
ignore = <TT><I>pattern</I></TT>
</PRE>
adds <TT><I>pattern</I></TT> to the list of patterns to be ignored.<BR>
<BR>
<LI CLASS="li-itemize">Each <TT><I>pattern</I></TT> can have one of three forms. The most
general form is a Posix extended regular expression introduced by the
keyword <CODE>Regex</CODE>. (The collating sequences and character classes of
full Posix regexps are not currently supported).
<PRE>
Regex <TT><I>regexp</I></TT>
</PRE>
For convenience, two other styles of pattern are also recognized:
<PRE>
Name <TT><I>name</I></TT>
</PRE>
matches any path in which the last component matches <TT><I>name</I></TT>, while
<PRE>
Path <TT><I>path</I></TT>
</PRE>
matches exactly the path <TT><I>path</I></TT>.
The <TT><I>name</I></TT> and <TT><I>path</I></TT> arguments of the latter forms of
patterns are <EM>not</EM> regular expressions. Instead,
standard &#8220;globbing&#8221; conventions can be used in <TT><I>name</I></TT> and
<TT><I>path</I></TT>:
<UL CLASS="itemize"><LI CLASS="li-itemize">
a <CODE>?</CODE> matches any single character except <CODE>/</CODE>
<LI CLASS="li-itemize">a <CODE>*</CODE> matches any sequence of characters not including <CODE>/</CODE>
(and not beginning with <CODE>.</CODE>, when used at the beginning of a
<TT><I>name</I></TT>)
<LI CLASS="li-itemize"><CODE>[xyz]</CODE> matches any character from the set {<TT><I>x</I></TT>,
<TT><I>y</I></TT>, <TT><I>z</I></TT> }
<LI CLASS="li-itemize"><CODE>{a,bb,ccc}</CODE> matches any one of <CODE>a</CODE>, <CODE>bb</CODE>, or
<CODE>ccc</CODE>.
</UL>
<LI CLASS="li-itemize">The path separator in path patterns is always the
forward-slash character &#8220;/&#8221; &mdash; even when the client or server is
running under Windows, where the normal separator character is a
backslash. This makes it possible to use the same set of path
patterns for both Unix and Windows file systems.
</UL>
Some examples of path patterns appear in the <A HREF="#ignore">Ignoring
Paths</A> section.<BR>
<BR>
<!--TOC subsection Ignoring Paths-->
<H3 CLASS="subsection"><A NAME="ignore"></A>Ignoring Paths</H3><!--SEC END -->
Most users of Unison will find that their replicas contain lots of
files that they don't ever want to synchronize &mdash; temporary files,
very large files, old stuff, architecture-specific binaries, etc.
They can instruct Unison to ignore these paths using patterns
introduced in the <A HREF="#pathspec">Path Patterns</A> section.<BR>
<BR>
For example, the following pattern will make Unison ignore any
path containing the name <CODE>CVS</CODE> or a name ending in <CODE>.cmo</CODE>:
<PRE CLASS="verbatim">
ignore = Name {CVS,*.cmo}
</PRE>The next pattern makes Unison ignore the path <CODE>a/b</CODE>:
<PRE CLASS="verbatim">
ignore = Path a/b
</PRE>Path patterns do <EM>not</EM> skip filesnames beginning with <CODE>.</CODE> (as Name
patterns do). For example,
<PRE CLASS="verbatim">
ignore = Path */tmp
</PRE>will include <CODE>.foo/tmp</CODE> in the set of ignore directories, as it is a
path, not a name, that is ignored.<BR>
<BR>
The following pattern makes Unison ignore any path beginning with <CODE>a/b</CODE>
and ending with a name ending by <CODE>.ml</CODE>.
<PRE CLASS="verbatim">
ignore = Regex a/b/.*\.ml
</PRE>Note that regular expression patterns are &#8220;anchored&#8221;: they must
match the whole path, not just a substring of the path.<BR>
<BR>
Here are a few extra points regarding the <TT>ignore</TT> preference.
<UL CLASS="itemize"><LI CLASS="li-itemize">
If a directory is ignored, all its descendents will be too.<BR>
<BR>
<LI CLASS="li-itemize">The user interface provides some convenient commands for adding
new patterns to be ignored. To ignore a particular file, select it
and press &#8220;<TT>i</TT>&#8221;. To ignore all files with the same extension,
select it and press &#8220;<TT>E</TT>&#8221; (with the shift key). To ignore all
files with the same name, no matter what directory they appear in,
select it and press &#8220;<TT>N</TT>&#8221;.
These new patterns become permanent: they
are immediately added to the current profile on disk.<BR>
<BR>
<LI CLASS="li-itemize">If you use the <CODE>include</CODE> directive to include a common
collection of preferences in several top-level preference files, you will
probably also want to set the <CODE>addprefsto</CODE> preference to the name of
this file. This will cause any new ignore patterns that you add from
inside Unison to be appended to this file, instead of whichever top-level
preference file you started Unison with. <BR>
<BR>
<LI CLASS="li-itemize">Ignore patterns can also be specified on the command line, if
you like (this is probably not very useful), using an option like
<CODE>-ignore 'Name temp.txt'</CODE>.<BR>
<BR>
<LI CLASS="li-itemize">Be careful about renaming directories containing ignored files.
Because Unison understands the rename as a delete plus a create, any ignored
files in the directory will be lost (since they are invisible to Unison and
therefore they do not get recreated in the new version of the directory).
</UL>
<!--TOC subsection Symbolic Links-->
<H3 CLASS="subsection"><A NAME="symlinks"></A>Symbolic Links</H3><!--SEC END -->
Ordinarily, Unison treats symbolic links in Unix replicas as
&#8220;opaque&#8221;: it considers the contents of the link to be just the
string specifying where the link points, and it will propagate changes in
this string to the other replica.<BR>
<BR>
It is sometimes useful to treat a symbolic link &#8220;transparently,&#8221;
acting as though whatever it points to were physically <EM>in</EM> the
replica at the point where the symbolic link appears. To tell Unison
to treat a link in this manner, add a line of the form
<PRE>
follow = <TT><I>pathspec</I></TT>
</PRE>
to the profile, where <TT><I>pathspec</I></TT> is a path pattern as described in
the <A HREF="#pathspec">Path Patterns</A> section.<BR>
<BR>
Windows file systems do not support symbolic links; Unison will refuse
to propagate an opaque symbolic link from Unix to Windows and flag the
path as erroneous. When a Unix replica is to be synchronized with a
Windows system, all symbolic links should match either an
<CODE>ignore</CODE> pattern or a <CODE>follow</CODE> pattern.<BR>
<BR>
<!--TOC subsection Permissions-->
<H3 CLASS="subsection"><A NAME="perms"></A>Permissions</H3><!--SEC END -->
Synchronizing the permission bits of files is slightly tricky when two
different filesytems are involved (e.g., when synchronizing a Windows
client and a Unix server). In detail, here's how it works:
<UL CLASS="itemize"><LI CLASS="li-itemize">
When the permission bits of an existing file or directory are
changed, the values of those bits that make sense on <EM>both</EM>
operating systems will be propagated to the other replica. The other
bits will not be changed.
<LI CLASS="li-itemize">When a newly created file is propagated to a remote replica, the
permission bits that make sense in both operating systems are also
propagated. The values of the other bits are set to default values
(they are taken from the current umask, if the receiving host is a
Unix system).
<LI CLASS="li-itemize">For security reasons, the Unix <CODE>setuid</CODE> and <CODE>setgid</CODE>
bits are not propagated.
<LI CLASS="li-itemize">The Unix owner and group ids are not propagated. (What would
this mean, in general?) All files are created with the owner and
group of the server process.
</UL>
<!--TOC subsection Cross-Platform Synchronization-->
<H3 CLASS="subsection"><A NAME="crossplatform"></A>Cross-Platform Synchronization</H3><!--SEC END -->
If you use Unison to synchronize files between Windows and Unix
systems, there are a few special issues to be aware of.<BR>
<BR>
<B>Case conflicts.</B> In Unix, filenames are case sensitive:
<TT>foo</TT> and <TT>FOO</TT> can refer to different files. In
Windows, on the other hand, filenames are not case sensitive:
<TT>foo</TT> and <TT>FOO</TT> can only refer to the same file. This
means that a Unix <TT>foo</TT> and <TT>FOO</TT> cannot be synchronized
onto a Windows system &mdash; Windows won't allow two different files to
have the &#8220;same&#8221; name. Unison detects this situation for you, and
reports that it cannot synchronize the files. <BR>
<BR>
You can deal with a case conflict in a couple of ways. If you need to
have both files on the Windows system, your only choice is to rename
one of the Unix files to avoid the case conflict, and re-synchronize.
If you don't need the files on the Windows system, you can simply
disregard Unison's warning message, and go ahead with the
synchronization; Unison won't touch those files. If you don't want to
see the warning on each synchronization, you can tell Unison to ignore
the files (see the <A HREF="#ignore">Ignore</A> section).<BR>
<BR>
<B>Illegal filenames.</B> Unix allows some filenames that are
illegal in Windows. For example, colons (`:') are not allowed in
Windows filenames, but they are legal in Unix filenames. This means
that a Unix file <TT>foo:bar</TT> can't be synchronized to a Windows
system. As with case conflicts, Unison detects this situation for
you, and you have the same options: you can either rename the Unix
file and re-synchronize, or you can ignore it.<BR>
<BR>
<!--TOC subsection Slow Links-->
<H3 CLASS="subsection"><A NAME="speed"></A>Slow Links</H3><!--SEC END -->
Unison is built to run well even over relatively slow links such as
modems and DSL connections. <BR>
<BR>
Unison uses the &#8220;rsync protocol&#8221; designed by Andrew Tridgell and Paul
Mackerras to greatly speed up transfers of large files in which only
small changes have been made. More information about the rsync protocol
can be found at the rsync web site (<A HREF="http://samba.anu.edu.au/rsync/"><TT>http://samba.anu.edu.au/rsync/</TT></A>).<BR>
<BR>
If you are using Unison with <TT>ssh</TT>, you may get some speed
improvement by enabling <TT>ssh</TT>'s compression feature. Do this by
adding the option &#8220;<TT>-rshargs -C</TT>&#8221; to the command line or &#8220;<TT>rshargs = -C</TT>&#8221; to your profile. <BR>
<BR>
<!--TOC subsection Fast Update Detection-->
<H3 CLASS="subsection"><A NAME="fastcheck"></A>Fast Update Detection</H3><!--SEC END -->
If your replicas are large and at least one of them is on a Windows
system, you may find that Unison's default method for detecting changes
(which involves scanning the full contents of every file on every
sync&mdash;the only completely safe way to do it under Windows) is too slow.
Unison provides a preference <TT>fastcheck</TT> that, when set to
<CODE>yes</CODE>, causes it to use file creation times as 'pseudo inode
numbers' when scanning replicas for updates, instead of reading the full
contents of every file. <BR>
<BR>
When <CODE>fastcheck</CODE> is set to <CODE>no</CODE>,
Unison will perform slow checking&mdash;re-scanning the contents of each file
on each synchronization&mdash;on all replicas. When <CODE>fastcheck</CODE> is set
to <CODE>default</CODE> (which, naturally, is the default), Unison will use
fast checks on Unix replicas and slow checks on Windows replicas.<BR>
<BR>
This strategy may cause Unison to miss propagating an update if the
create time, modification time, and length of the file are all unchanged
by the update (this is not easy to achieve, but it can be done).
However, Unison will never <EM>overwrite</EM> such an update with a change
from the other replica, since it always does a safe check for updates
just before propagating a change. Thus, it is reasonable to use this
switch most of the time and occasionally run Unison once with <TT>fastcheck</TT> set to <CODE>no</CODE>, if you are worried that Unison may have
overlooked an update.<BR>
<BR>
<!--TOC subsection Click-starting Unison-->
<H3 CLASS="subsection"><A NAME="click"></A>Click-starting Unison</H3><!--SEC END -->
On Windows NT/2k/XP systems, the graphical version of Unison can be
invoked directly by clicking on its icon. On Windows 95/98 systems,
click-starting also works, <EM>as long as you are not using ssh</EM>.
Due to an incompatibility with ocaml and Windows 95/98 that is not
under our control, you must start Unison from a DOS window in Windows
95/98 if you want to use ssh.<BR>
<BR>
When you click on the Unison icon, two windows will be created:
Unison's regular window, plus a console window, which is used only for
giving your password to ssh (if you do not use ssh to connect, you can
ignore this window). When your password is requested, you'll need to
activate the console window (e.g., by clicking in it) before typing.
If you start Unison from a DOS window, Unison's regular window will
appear and you will type your password in the DOS window you were
using.<BR>
<BR>
To use Unison in this mode, you must first create a profile (see
the <A HREF="#profile">Profile</A> section). Use your favorite editor for this. <BR>
<BR>
<hr><!--TOC section Installing Ssh-->
<H2 CLASS="section"><A NAME="ssh"></A>Installing Ssh</H2><!--SEC END -->
Your local host will need just an ssh client; the remote host needs an
ssh server (or daemon), which is available on Unix systems. Unison is
known to work with ssh version 1.2.27 (Unix) and version 1.2.14
(Windows); other versions may or may not work.<BR>
<BR>
<!--TOC subsection Unix-->
<H3 CLASS="subsection"><A NAME="ssh-unix"></A>Unix</H3><!--SEC END -->
Most modern Unix installations come with <CODE>ssh</CODE> pre-installed.<BR>
<BR>
<!--TOC subsection Windows-->
<H3 CLASS="subsection"><A NAME="ssh-win"></A>Windows</H3><!--SEC END -->
Many Windows implementations of ssh only provide graphical interfaces,
but Unison requires an ssh client that it can invoke with a
command-line interface. A suitable version of ssh can be installed as
follows. (<EM>Warning: These instructions may be out of date.</EM>)
<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
Download an <CODE>ssh</CODE> executable. <BR>
<BR>
Warning: there are many implementations and ports of ssh for
Windows, and not all of them will work with Unison. We have gotten
Unison to work with Cygwin's port of openssh, and we suggest you try
that one first. Here's how to install it:
<OL CLASS="enumerate" type=a><LI CLASS="li-enumerate">
First, create a new folder on your desktop to hold temporary
installation files. It can have any name you like, but in these
instructions we'll assume that you call it <CODE>Foo</CODE>.
<LI CLASS="li-enumerate">Direct your web browser to www.cygwin.com, and click on the
&#8220;Install now!&#8221; link. This will download a file, <CODE>setup.exe</CODE>;
save it in the directory <CODE>Foo</CODE>. The file <CODE>setup.exe</CODE> is a
small program that will download the actual install files from
the Internet when you run it.
<LI CLASS="li-enumerate">Start <CODE>setup.exe</CODE> (by double-clicking). This brings up a
series of dialogs that you will have to go through. Select
&#8220;Install from Internet.&#8221; For &#8220;Local Package Directory&#8221; select
the directory <CODE>Foo</CODE>. For &#8220;Select install root directory&#8221; we
recommend that you use the default, <CODE>C:\cygwin</CODE>. The next
dialog asks you to select the way that you want to connect to the
network to download the installation files; we have used &#8220;Use IE5
Settings&#8221; successfully, but you may need to make a different
selection depending on your networking setup. The next dialog gives
a list of mirrors; select one close to you.<BR>
<BR>
Next you are asked to select which packages to install. The default
settings in this dialog download a lot of packages that are not
strictly necessary to run Unison with ssh. If you don't want to
install a package, click on it until &#8220;skip&#8221; is shown. For a
minimum installation, select only the packages &#8220;cygwin&#8221; and
&#8220;openssh,&#8221; which come to about 1900KB; the full installation is
much larger.
<BLOCKQUOTE CLASS="quote"> <EM>Note that you are plan to build unison using the free
CygWin GNU C compiler, you need to install essential development
packages such as &#8220;gcc&#8221;, &#8220;make&#8221;, &#8220;fileutil&#8221;, etc; we refer to
the file &#8220;INSTALL.win32-cygwin-gnuc&#8221; in the source distribution
for further details.
</EM></BLOCKQUOTE>
After the packages are downloaded and installed, the next dialog
allows you to choose whether to &#8220;Create Desktop Icon&#8221; and &#8220;Add to
Start Menu.&#8221; You make the call.
<LI CLASS="li-enumerate">You can now delete the directory <CODE>Foo</CODE> and its contents.
</OL>
Some people have reported problems using Cygwin's ssh with Unison. If
you have trouble, you might try this one instead:
<PRE CLASS="verbatim">
http://opensores.thebunker.net/pub/mirrors/ssh/contrib/ssh-1.2.14-win32bin.zip
</PRE><BR>
<BR>
<LI CLASS="li-enumerate">You must set the environment variables HOME and PATH.
Ssh will create a directory <CODE>.ssh</CODE> in the directory given
by HOME, so that it has a place to keep data like your public and
private keys. PATH must be set to include the Cygwin <CODE>bin</CODE>
directory, so that Unison can find the ssh executable.
<UL CLASS="itemize"><LI CLASS="li-itemize">
On Windows 95/98, add the lines
<PRE CLASS="verbatim">
set PATH=%PATH%;&lt;SSHDIR&gt;
set HOME=&lt;HOMEDIR&gt;
</PRE>to the file <CODE>C:\AUTOEXEC.BAT</CODE>, where <CODE>&lt;HOMEDIR&gt;</CODE> is the
directory where you want ssh to create its <CODE>.ssh</CODE> directory,
and <CODE>&lt;SSHDIR&gt;</CODE> is the directory where the executable
<CODE>ssh.exe</CODE> is stored; if you've installed Cygwin in the
default location, this is <CODE>C:\cygwin\bin</CODE>. You will have to
reboot your computer to take the changes into account.
<LI CLASS="li-itemize">On Windows NT/2k/XP, open the environment variables dialog box:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Windows NT: My Computer/Properties/Environment
<LI CLASS="li-itemize">Windows 2k: My Computer/Properties/Advanced/Environment
variables
</UL>
then select Path and edit its value by appending <CODE>;&lt;SSHDIR&gt;</CODE>
to it, where <CODE>&lt;SSHDIR&gt;</CODE> is the full name of the directory
that includes the ssh executable; if you've installed Cygwin in
the default location, this is <CODE>C:\cygwin\bin</CODE>.
</UL>
<LI CLASS="li-enumerate">Test ssh from a DOS shell by typing
<PRE CLASS="verbatim">
ssh &lt;remote host&gt; -l &lt;login name&gt;
</PRE>You should get a prompt for your password on <CODE>&lt;remote host&gt;</CODE>,
followed by a working connection.
<LI CLASS="li-enumerate">Note that <CODE>ssh-keygen</CODE> may not work (fails with
&#8220;gethostname: no such file or directory&#8221;) on some systems. This is
OK: you can use ssh with your regular password for the remote
system.
<LI CLASS="li-enumerate">You should now be able to use Unison with an ssh connection. If
you are logged in with a different user name on the local and remote
hosts, provide your remote user name when providing the remote root
(i.e., <CODE>//username@host/path...</CODE>).
</OL>
<hr><!--TOC section Changes in Version 2.17.1-->
<H2 CLASS="section"><A NAME="news"></A>Changes in Version 2.17.1</H2><!--SEC END -->
Changes since 2.13.0:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The features for performing backups and for invoking external merge
programs have been completely rewritten by Stephane Lescuyer (thanks,
Stephane!). The user-visible functionality should not change, but the
internals have been rationalized and there are a number of new features.
See the manual (in particular, the description of the <CODE>backupXXX</CODE>
preferences) for details.<BR>
<BR>
<LI CLASS="li-itemize">Incorporated patches for ipv6 support, contributed by Samuel Thibault.
(Note that, due to a bug in the released OCaml 3.08.3 compiler, this code
will not actually work with ipv6 unless compiled with the CVS version of the
OCaml compiler, where the bug has been fixed; however, ipv4 should continue
to work normally.)<BR>
<BR>
<LI CLASS="li-itemize">OSX interface:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Incorporated Ben Willmore's cool new icon for the Mac UI.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Small fixes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Fixed off by one error in month numbers (in printed dates) reported
by Bob Burger
</UL><BR>
</UL>
Changes since 2.12.0:
<UL CLASS="itemize"><LI CLASS="li-itemize">
New convention for release numbering: Releases will continue to be
given numbers of the form <CODE>X.Y.Z</CODE>, but,
from now on, just the major version number (<CODE>X.Y</CODE>) will be considered
significant when checking compatibility between client and server versions.
The third component of the version number will be used only to identify
&#8220;patch levels&#8221; of releases.<BR>
<BR>
This change goes hand in hand with a change to the procedure for making new
releases. Candidate releases will initially be given &#8220;beta release&#8221;
status when they are announced for public consumption. Any bugs that are
discovered will be fixed in a separate branch of the source repository
(without changing the major version number) and new tarballs re-released as
needed. When this process converges, the patched beta version will be
dubbed stable.<BR>
<BR>
<LI CLASS="li-itemize">Warning (failure in batch mode) when one path is completely emptied.
This prevents Unison from deleting everything on one replica when
the other disappear.<BR>
<BR>
<LI CLASS="li-itemize">Fix diff bug (where no difference is shown the first time the diff
command is given).<BR>
<BR>
<LI CLASS="li-itemize">User interface changes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Improved workaround for button focus problem (GTK2 UI)
<LI CLASS="li-itemize">Put leading zeroes in date fields
<LI CLASS="li-itemize">More robust handling of character encodings in GTK2 UI
<LI CLASS="li-itemize">Changed format of modification time displays, from <CODE>modified at hh:mm:ss on dd MMM, yyyy</CODE>
to <CODE>modified on yyyy-mm-dd hh:mm:ss</CODE>
<LI CLASS="li-itemize">Changed time display to include seconds (so that people on FAT
filesystems will not be confused when Unison tries to update a file
time to an odd number of seconds and the filesystem truncates it to
an even number!)
<LI CLASS="li-itemize">Use the diff "-u" option by default when showing differences between files
(the output is more readable)
<LI CLASS="li-itemize">In text mode, pipe the diff output to a pager if the environment
variable PAGER is set
<LI CLASS="li-itemize">Bug fixes and cleanups in ssh password prompting. Now works with
the GTK2 UI under Linux. (Hopefully the Mac OS X one is not broken!)
<LI CLASS="li-itemize">Include profile name in the GTK2 window name
<LI CLASS="li-itemize">Added bindings ',' (same as '&lt;') and '.' (same as '&gt;') in the GTK2 UI
</UL><BR>
<BR>
<LI CLASS="li-itemize">Mac GUI:
<UL CLASS="itemize"><LI CLASS="li-itemize">
actions like &lt; and &gt; scroll to the next item as necessary.
<LI CLASS="li-itemize">Restart has a menu item and keyboard shortcut (command-R).
<LI CLASS="li-itemize">Added a command-line tool for Mac OS X. It can be installed from
the Unison menu.
<LI CLASS="li-itemize">New icon.
<LI CLASS="li-itemize">Handle the "help" command-line argument properly.
<LI CLASS="li-itemize">Handle profiles given on the command line properly.
<LI CLASS="li-itemize">When a profile has been selected, the profile dialog is replaced by a
"connecting" message while the connection is being made. This
gives better feedback.
<LI CLASS="li-itemize">Size of left and right columns is now large enough so that
"PropsChanged" is not cut off.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Minor changes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Disable multi-threading when both roots are local
<LI CLASS="li-itemize">Improved error handling code. In particular, make sure all files
are closed in case of a transient failure
<LI CLASS="li-itemize">Under Windows, use <CODE>$UNISON</CODE> for home directory as a last resort
(it was wrongly moved before <CODE>$HOME</CODE> and <CODE>$USERPROFILE</CODE> in
Unison 2.12.0)
<LI CLASS="li-itemize">Reopen the logfile if its name changes (profile change)
<LI CLASS="li-itemize">Double-check that permissions and modification times have been
properly set: there are some combination of OS and filesystem on
which setting them can fail in a silent way.
<LI CLASS="li-itemize">Check for bad Windows filenames for pure Windows synchronization
also (not just cross architecture synchronization).
This way, filenames containing backslashes, which are not correctly
handled by unison, are rejected right away.
<LI CLASS="li-itemize">Attempt to resolve issues with synchronizing modification times
of read-only files under Windows
<LI CLASS="li-itemize">Ignore chmod failures when deleting files
<LI CLASS="li-itemize">Ignore trailing dots in filenames in case insensitive mode
<LI CLASS="li-itemize">Proper quoting of paths, files and extensions ignored using the UI
<LI CLASS="li-itemize">The strings CURRENT1 and CURRENT2 are now correctly substitued when
they occur in the diff preference
<LI CLASS="li-itemize">Improvements to syncing resource forks between Macs via a non-Mac system.
</UL><BR>
</UL>
Changes since 2.10.2:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
Archive format has changed. <BR>
<BR>
<LI CLASS="li-itemize">Source code availability: The Unison sources are now managed using
Subversion. One nice side-effect is that anonymous checkout is now
possible, like this:
<PRE CLASS="verbatim">
svn co https://cvs.cis.upenn.edu:3690/svnroot/unison/
</PRE>We will also continue to export a &#8220;developer tarball&#8221; of the current
(modulo one day) sources in the web export directory. To receive commit logs
for changes to the sources, subscribe to the <CODE>unison-hackers</CODE> list
(<A HREF="http://www.cis.upenn.edu/ bcpierce/unison/lists.html"><TT>http://www.cis.upenn.edu/&nbsp;bcpierce/unison/lists.html</TT></A>). <BR>
<BR>
<LI CLASS="li-itemize">Text user interface:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Substantial reworking of the internal logic of the text UI to make it
a bit easier to modify.
<LI CLASS="li-itemize">The <TT>dumbtty</TT> flag in the text UI is automatically set to true if
the client is running on a Unix system and the <TT>EMACS</TT> environment
variable is set to anything other than the empty string.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Native OS X gui:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Added a synchronize menu item with keyboard shortcut
<LI CLASS="li-itemize">Added a merge menu item, still needs to be debugged
<LI CLASS="li-itemize">Fixes to compile for Panther
<LI CLASS="li-itemize">Miscellaneous improvements and bugfixes
</UL><BR>
<BR>
<LI CLASS="li-itemize">Small changes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Changed the filename checking code to apply to Windows only, instead
of OS X as well.
<LI CLASS="li-itemize">Finder flags now synchronized
<LI CLASS="li-itemize">Fallback in copy.ml for filesystem that do not support <CODE>O_EXCL</CODE>
<LI CLASS="li-itemize">Changed buffer size for local file copy (was highly inefficient with
synchronous writes)
<LI CLASS="li-itemize">Ignore chmod failure when deleting a directory
<LI CLASS="li-itemize">Fixed assertion failure when resolving a conflict content change /
permission changes in favor of the content change.
<LI CLASS="li-itemize">Workaround for transferring large files using rsync.
<LI CLASS="li-itemize">Use buffered I/O for files (this is the only way to open files in binary
mode under Cygwin).
<LI CLASS="li-itemize">On non-Cygwin Windows systems, the UNISON environment variable is now checked first to determine
where to look for Unison's archive and preference files, followed by <CODE>HOME</CODE> and
<CODE>USERPROFILE</CODE> in that order. On Unix and Cygwin systems, <CODE>HOME</CODE> is used.
<LI CLASS="li-itemize">Generalized <CODE>diff</CODE> preference so that it can be given either as just
the command name to be used for calculating diffs or else a whole command
line, containing the strings <CODE>CURRENT1</CODE> and <CODE>CURRENT2</CODE>, which will be replaced
by the names of the files to be diff'ed before the command is called.
<LI CLASS="li-itemize">Recognize password prompts in some newer versions of ssh.
</UL>
</UL>
Changes since 2.9.20:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
Archive format has changed.
<LI CLASS="li-itemize">Major functionality changes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Major tidying and enhancement of 'merge' functionality. The main
user-visible change is that the external merge program may either write
the merged output to a single new file, as before, or it may modify one or
both of its input files, or it may write <EM>two</EM> new files. In the
latter cases, its modifications will be copied back into place on both the
local and the remote host, and (if the two files are now equal) the
archive will be updated appropriately. More information can be found in
the user manual. Thanks to Malo Denielou and Alan Schmitt for these
improvements.<BR>
<BR>
Warning: the new merging functionality is not completely compatible with
old versions! Check the manual for details.<BR>
<BR>
<LI CLASS="li-itemize">Files larger than 2Gb are now supported.<BR>
<BR>
<LI CLASS="li-itemize">Added preliminary (and still somewhat experimental) support for the
Apple OS X operating system.
<UL CLASS="itemize"><LI CLASS="li-itemize">
Resource forks should be transferred correctly. (See the manual for
details of how this works when synchronizing HFS with non-HFS volumes.)
Synchronization of file type and creator information is also supported.
<LI CLASS="li-itemize">On OSX systems, the name of the directory for storing Unison's
archives, preference files, etc., is now determined as follows:
<UL CLASS="itemize"><LI CLASS="li-itemize">
if <CODE>~/.unison</CODE> exists, use it
<LI CLASS="li-itemize">otherwise, use <CODE>~/Library/Application Support/Unison</CODE>,
creating it if necessary.
</UL>
<LI CLASS="li-itemize">A preliminary native-Cocoa user interface is under construction. This
still needs some work, and some users experience unpredictable crashes, so
it is only for hackers for now. Run make with <TT>UISTYLE=mac</TT> to build
this interface.
</UL>
</UL><BR>
<BR>
<LI CLASS="li-itemize">Minor functionality changes:
<UL CLASS="itemize"><LI CLASS="li-itemize">Added an <TT>ignorelocks</TT> preference, which forces Unison to override left-over
archive locks. (Setting this preference is dangerous! Use it only if you
are positive you know what you are doing.)
<LI CLASS="li-itemize">Running with the <TT>-timers</TT> flag set to true will now show the total time taken
to check for updates on each directory. (This can be helpful for tidying directories to improve
update detection times.)
<LI CLASS="li-itemize">Added a new preference <TT>assumeContentsAreImmutable</TT>. If a directory
matches one of the patterns set in this preference, then update detection
is skipped for files in this directory. (The
purpose is to speed update detection for cases like Mail folders, which
contain lots and lots of immutable files.) Also a preference
<TT>assumeContentsAreImmutableNot</TT>, which overrides the first, similarly
to <TT>ignorenot</TT>. (Later amendment: these preferences are now called
<TT>immutable</TT> and <TT>immutablenot</TT>.)<BR>
<BR>
<LI CLASS="li-itemize">The <TT>ignorecase</TT> flag has been changed from a boolean to a three-valued
preference. The default setting, called <TT>default</TT>, checks the operating systems
running on the client and server and ignores filename case if either of them is
OSX or Windows. Setting ignorecase to <TT>true</TT> or <TT>false</TT> overrides
this behavior. If you have been setting <TT>ignorecase</TT> on the command
line using <TT>-ignorecase=true</TT> or <TT>-ignorecase=false</TT>, you will
need to change to <TT>-ignorecase true</TT> or <TT>-ignorecase false</TT>.<BR>
<BR>
<LI CLASS="li-itemize">a new preference, 'repeat', for the text user interface (only). If 'repeat' is set to
a number, then, after it finishes synchronizing, Unison will wait for that many seconds and
then start over, continuing this way until it is killed from outside. Setting repeat to true
will automatically set the batch preference to true. <BR>
<BR>
<LI CLASS="li-itemize">Excel files are now handled specially, so that the <TT>fastcheck</TT>
optimization is skipped even if the <TT>fastcheck</TT> flag is set. (Excel
does some naughty things with modtimes, making this optimization
unreliable and leading to failures during change propagation.)<BR>
<BR>
<LI CLASS="li-itemize">The ignorecase flag has been changed from a boolean to a three-valued
preference. The default setting, called 'default', checks the operating systems
running on the client and server and ignores filename case if either of them is
OSX or Windows. Setting ignorecase to 'true' or 'false' overrides this behavior.<BR>
<BR>
<LI CLASS="li-itemize">Added a new preference, 'repeat', for the text user interface (only,
at the moment). If 'repeat' is set to a number, then, after it finishes
synchronizing, Unison will wait for that many seconds and then start over,
continuing this way until it is killed from outside. Setting repeat to
true will automatically set the batch preference to true.<BR>
<BR>
<LI CLASS="li-itemize">The 'rshargs' preference has been split into 'rshargs' and 'sshargs'
(mainly to make the documentation clearer). In fact, 'rshargs' is no longer
mentioned in the documentation at all, since pretty much everybody uses
ssh now anyway.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Documentation
<UL CLASS="itemize"><LI CLASS="li-itemize">
The web pages have been completely redesigned and reorganized.
(Thanks to Alan Schmitt for help with this.)
</UL><BR>
<BR>
<LI CLASS="li-itemize">User interface improvements
<UL CLASS="itemize"><LI CLASS="li-itemize">
Added a GTK2 user interface, capable (among other things) of displaying filenames
in any locale encoding. Kudos to Stephen Tse for contributing this code!
<LI CLASS="li-itemize">The text UI now prints a list of failed and skipped transfers at the end of
synchronization.
<LI CLASS="li-itemize">Restarting update detection from the graphical UI will reload the current
profile (which in particular will reset the -path preference, in case
it has been narrowed by using the &#8220;Recheck unsynchronized items&#8221;
command).
<LI CLASS="li-itemize">Several small improvements to the text user interface, including a
progress display.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Bug fixes (too numerous to count, actually, but here are some):
<UL CLASS="itemize"><LI CLASS="li-itemize">
The <TT>maxthreads</TT> preference works now.
<LI CLASS="li-itemize">Fixed bug where warning message about uname returning an unrecognized
result was preventing connection to server. (The warning is no longer
printed, and all systems where 'uname' returns anything other than 'Darwin'
are assumed not to be running OS X.)
<LI CLASS="li-itemize">Fixed a problem on OS X that caused some valid file names (e.g.,
those including colons) to be considered invalid.
<LI CLASS="li-itemize">Patched Path.followLink to follow links under cygwin in addition to Unix
(suggested by Matt Swift).
<LI CLASS="li-itemize">Small change to the storeRootsName function, suggested by bliviero at
ichips.intel.com, to fix a problem in unison with the `rootalias'
option, which allows you to tell unison that two roots contain the same
files. Rootalias was being applied after the hosts were
sorted, so it wouldn't work properly in all cases.
<LI CLASS="li-itemize">Incorporated a fix by Dmitry Bely for setting utimes of read-only files
on Win32 systems.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Installation / portability:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Unison now compiles with OCaml version 3.07 and later out of the box.
<LI CLASS="li-itemize">Makefile.OCaml fixed to compile out of the box under OpenBSD.
<LI CLASS="li-itemize">a few additional ports (e.g. OpenBSD, Zaurus/IPAQ) are now mentioned in
the documentation
<LI CLASS="li-itemize">Unison can now be installed easily on OSX systems using the Fink
package manager
</UL>
</UL>
Changes since 2.9.1:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Added a preference <TT>maxthreads</TT> that can be used to limit the
number of simultaneous file transfers.
<LI CLASS="li-itemize">Added a <TT>backupdir</TT> preference, which controls where backup
files are stored.
<LI CLASS="li-itemize">Basic support added for OSX. In particular, Unison now recognizes
when one of the hosts being synchronized is running OSX and switches to
a case-insensitive treatment of filenames (i.e., 'foo' and 'FOO' are
considered to be the same file).
(OSX is not yet fully working,
however: in particular, files with resource forks will not be
synchronized correctly.)
<LI CLASS="li-itemize">The same hash used to form the archive name is now also added to
the names of the temp files created during file transfer. The reason for
this is that, during update detection, we are going to silently delete
any old temp files that we find along the way, and we want to prevent
ourselves from deleting temp files belonging to other instances of Unison
that may be running in parallel, e.g. synchronizing with a different
host. Thanks to Ruslan Ermilov for this suggestion.
<LI CLASS="li-itemize">Several small user interface improvements
<LI CLASS="li-itemize">Documentation
<UL CLASS="itemize"><LI CLASS="li-itemize">
FAQ and bug reporting instructions have been split out as separate
HTML pages, accessible directly from the unison web page.
<LI CLASS="li-itemize">Additions to FAQ, in particular suggestions about performance
tuning.
</UL>
<LI CLASS="li-itemize">Makefile
<UL CLASS="itemize"><LI CLASS="li-itemize">
Makefile.OCaml now sets UISTYLE=text or UISTYLE=gtk automatically,
depending on whether it finds lablgtk installed
<LI CLASS="li-itemize">Unison should now compile &#8220;out of the box&#8221; under OSX
</UL>
</UL>
Changes since 2.8.1:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Changing profile works again under Windows
<LI CLASS="li-itemize">File movement optimization: Unison now tries to use local copy instead of
transfer for moved or copied files. It is controled by a boolean option
&#8220;xferbycopying&#8221;.
<LI CLASS="li-itemize">Network statistics window (transfer rate, amount of data transferred).
[NB: not available in Windows-Cygwin version.]
<LI CLASS="li-itemize">symlinks work under the cygwin version (which is dynamically linked).
<LI CLASS="li-itemize">Fixed potential deadlock when synchronizing between Windows and
Unix
<LI CLASS="li-itemize">Small improvements:
<UL CLASS="itemize"><LI CLASS="li-itemize">
If neither the <BR>
tt USERPROFILE nor the <BR>
tt HOME environment
variables are set, then Unison will put its temporary commit log
(called <BR>
tt DANGER.README) into the directory named by the
<BR>
tt UNISON environment variable, if any; otherwise it will use
<BR>
tt C:.
<LI CLASS="li-itemize">alternative set of values for fastcheck: yes = true; no = false;
default = auto.
<LI CLASS="li-itemize">-silent implies -contactquietly
</UL>
<LI CLASS="li-itemize">Source code:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Code reorganization and tidying. (Started breaking up some of the
basic utility modules so that the non-unison-specific stuff can be
made available for other projects.)
<LI CLASS="li-itemize">several Makefile and docs changes (for release);
<LI CLASS="li-itemize">further comments in &#8220;update.ml&#8221;;
<LI CLASS="li-itemize">connection information is not stored in global variables anymore.
</UL>
</UL>
Changes since 2.7.78:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Small bugfix to textual user interface under Unix (to avoid leaving
the terminal in a bad state where it would not echo inputs after Unison
exited).
</UL>
Changes since 2.7.39:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Improvements to the main web page (stable and beta version docs are
now both accessible).
<LI CLASS="li-itemize">User manual revised.
<LI CLASS="li-itemize">Added some new preferences:
<UL CLASS="itemize"><LI CLASS="li-itemize">
&#8220;sshcmd&#8221; and &#8220;rshcmd&#8221; for specifying paths to ssh and rsh programs.
<LI CLASS="li-itemize">&#8220;contactquietly&#8221; for suppressing the &#8220;contacting server&#8221; message
during Unison startup (under the graphical UI).
</UL>
<LI CLASS="li-itemize">Bug fixes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Fixed small bug in UI that neglected to change the displayed column
headers if loading a new profile caused the roots to change.
<LI CLASS="li-itemize">Fixed a bug that would put the text UI into an infinite loop if it
encountered a conflict when run in batch mode.
<LI CLASS="li-itemize">Added some code to try to fix the display of non-Ascii characters in
filenames on Windows systems in the GTK UI. (This code is currently
untested&mdash;if you're one of the people that had reported problems with
display of non-ascii filenames, we'd appreciate knowing if this actually
fixes things.)
<LI CLASS="li-itemize">`<CODE>-prefer/-force newer</CODE>' works properly now.
(The bug was reported by Sebastian Urbaniak and Sean Fulton.)
</UL>
<LI CLASS="li-itemize">User interface and Unison behavior:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Renamed `Proceed' to `Go' in the graphical UI.
<LI CLASS="li-itemize">Added exit status for the textual user interface.
<LI CLASS="li-itemize">Paths that are not synchronized because of conflicts or errors during
update detection are now noted in the log file.
<LI CLASS="li-itemize"><CODE>[END]</CODE> messages in log now use a briefer format
<LI CLASS="li-itemize">Changed the text UI startup sequence so that
<BR>
tt ./unison -ui text will use the default profile instead of failing.
<LI CLASS="li-itemize">Made some improvements to the error messages.
<LI CLASS="li-itemize">Added some debugging messages to remote.ml.
</UL>
</UL>
Changes since 2.7.7:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Incorporated, once again, a multi-threaded transport sub-system.
It transfers several files at the same time, thereby making much
more effective use of available network bandwidth. Unlike the
earlier attempt, this time we do not rely on the native thread
library of OCaml. Instead, we implement a light-weight,
non-preemptive multi-thread library in OCaml directly. This version
appears stable. <BR>
<BR>
Some adjustments to unison are made to accommodate the multi-threaded
version. These include, in particular, changes to the
user interface and logging, for example:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Two log entries for each transferring task, one for the
beginning, one for the end.
<LI CLASS="li-itemize">Suppressed warning messages against removing temp files left
by a previous unison run, because warning does not work nicely
under multi-threading. The temp file names are made less likely
to coincide with the name of a file created by the user. They
take the form<BR>
<CODE>.#&lt;filename&gt;.&lt;serial&gt;.unison.tmp</CODE>.
</UL>
<LI CLASS="li-itemize">Added a new command to the GTK user interface: pressing 'f' causes
Unison to start a new update detection phase, using as paths <EM>just</EM>
those paths that have been detected as changed and not yet marked as
successfully completed. Use this command to quickly restart Unison on
just the set of paths still needing attention after a previous run.
<LI CLASS="li-itemize">Made the <TT>ignorecase</TT> preference user-visible, and changed the
initialization code so that it can be manually set to true, even if
neither host is running Windows. (This may be useful, e.g., when using
Unison running on a Unix system with a FAT volume mounted.)
<LI CLASS="li-itemize">Small improvements and bug fixes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Errors in preference files now generate fatal errors rather than
warnings at startup time. (I.e., you can't go on from them.) Also,
we fixed a bug that was preventing these warnings from appearing in the
text UI, so some users who have been running (unsuspectingly) with
garbage in their prefs files may now get error reports.
<LI CLASS="li-itemize">Error reporting for preference files now provides file name and
line number.
<LI CLASS="li-itemize">More intelligible message in the case of identical change to the same
files: &#8220;Nothing to do: replicas have been changed only in identical
ways since last sync.&#8221;
<LI CLASS="li-itemize">Files with prefix '.#' excluded when scanning for preference
files.
<LI CLASS="li-itemize">Rsync instructions are send directly instead of first
marshaled.
<LI CLASS="li-itemize">Won't try forever to get the fingerprint of a continuously changing file:
unison will give up after certain number of retries.
<LI CLASS="li-itemize">Other bug fixes, including the one reported by Peter Selinger
(<CODE>force=older preference</CODE> not working).
</UL>
<LI CLASS="li-itemize">Compilation:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Upgraded to the new OCaml 3.04 compiler, with the LablGtk
1.2.3 library (patched version used for compiling under Windows).
<LI CLASS="li-itemize">Added the option to compile unison on the Windows platform with
Cygwin GNU C compiler. This option only supports building
dynamically linked unison executables.
</UL>
</UL>
Changes since 2.7.4:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Fixed a silly (but debilitating) bug in the client startup sequence.
</UL>
Changes since 2.7.1:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Added <CODE>addprefsto</CODE> preference, which (when set) controls which
preference file new preferences (e.g. new ignore patterns) are added to.
<LI CLASS="li-itemize">Bug fix: read the initial connection header one byte at a time, so
that we don't block if the header is shorter than expected. (This bug
did not affect normal operation &mdash; it just made it hard to tell when you
were trying to use Unison incorrectly with an old version of the server,
since it would hang instead of giving an error message.)
</UL>
Changes since 2.6.59:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Changed <CODE>fastcheck</CODE> from a boolean to a string preference. Its
legal values are <CODE>yes</CODE> (for a fast check), <CODE>no</CODE> (for a safe
check), or <CODE>default</CODE> (for a fast check&mdash;which also happens to be
safe&mdash;when running on Unix and a safe check when on Windows). The default
is <CODE>default</CODE>.
<LI CLASS="li-itemize">Several preferences have been renamed for consistency. All
preference names are now spelled out in lowercase. For backward
compatibility, the old names still work, but they are not mentioned in
the manual any more.
<LI CLASS="li-itemize">The temp files created by the 'diff' and 'merge' commands are now
named by <EM>pre</EM>pending a new prefix to the file name, rather than
appending a suffix. This should avoid confusing diff/merge programs
that depend on the suffix to guess the type of the file contents.
<LI CLASS="li-itemize">We now set the keepalive option on the server socket, to make sure
that the server times out if the communication link is unexpectedly broken.
<LI CLASS="li-itemize">Bug fixes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
When updating small files, Unison now closes the destination file.
<LI CLASS="li-itemize">File permissions are properly updated when the file is behind a
followed link.
<LI CLASS="li-itemize">Several other small fixes.
</UL>
</UL>
Changes since 2.6.38:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Major Windows performance improvement! <BR>
<BR>
We've added a preference <CODE>fastcheck</CODE> that makes Unison look only at
a file's creation time and last-modified time to check whether it has
changed. This should result in a huge speedup when checking for updates
in large replicas.<BR>
<BR>
When this switch is set, Unison will use file creation times as
'pseudo inode numbers' when scanning Windows replicas for updates,
instead of reading the full contents of every file. This may cause
Unison to miss propagating an update if the create time,
modification time, and length of the file are all unchanged by
the update (this is not easy to achieve, but it can be done).
However, Unison will never <EM>overwrite</EM> such an update with
a change from the other replica, since it
always does a safe check for updates just before propagating a
change. Thus, it is reasonable to use this switch most of the time
and occasionally run Unison once with <TT>fastcheck</TT> set to false,
if you are worried that Unison may have overlooked an update.<BR>
<BR>
Warning: This change is has not yet been thoroughly field-tested. If you
set the <CODE>fastcheck</CODE> preference, pay careful attention to what
Unison is doing.<BR>
<BR>
<LI CLASS="li-itemize">New functionality: centralized backups and merging
<UL CLASS="itemize"><LI CLASS="li-itemize">
This version incorporates two pieces of major new functionality,
implemented by Sylvain Roy during a summer internship at Penn: a
<EM>centralized backup</EM> facility that keeps a full backup of
(selected files
in) each replica, and a <EM>merging</EM> feature that allows Unison to
invoke an external file-merging tool to resolve conflicting changes to
individual files.<BR>
<BR>
<LI CLASS="li-itemize">Centralized backups:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Unison now maintains full backups of the last-synchronized versions
of (some of) the files in each replica; these function both as
backups in the usual sense
and as the &#8220;common version&#8221; when invoking external
merge programs.
<LI CLASS="li-itemize">The backed up files are stored in a directory &nbsp;/.unison/backup on each
host. (The name of this directory can be changed by setting
the environment variable <CODE>UNISONBACKUPDIR</CODE>.)
<LI CLASS="li-itemize">The predicate <CODE>backup</CODE> controls which files are actually
backed up:
giving the preference '<CODE>backup = Path *</CODE>' causes backing up
of all files.
<LI CLASS="li-itemize">Files are added to the backup directory whenever unison updates
its archive. This means that
<UL CLASS="itemize"><LI CLASS="li-itemize">
When unison reconstructs its archive from scratch (e.g.,
because of an upgrade, or because the archive files have
been manually deleted), all files will be backed up.
<LI CLASS="li-itemize">Otherwise, each file will be backed up the first time unison
propagates an update for it.
</UL>
<LI CLASS="li-itemize">The preference <CODE>backupversions</CODE> controls how many previous
versions of each file are kept. The default is 2 (i.e., the last
synchronized version plus one backup).
<LI CLASS="li-itemize">For backward compatibility, the <CODE>backups</CODE> preference is also
still supported, but <CODE>backup</CODE> is now preferred.
<LI CLASS="li-itemize">It is OK to manually delete files from the backup directory (or to throw
away the directory itself). Before unison uses any of these files for
anything important, it checks that its fingerprint matches the one
that it expects.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Merging:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Both user interfaces offer a new 'merge' command, invoked by pressing
'm' (with a changed file selected).
<LI CLASS="li-itemize">The actual merging is performed by an external program.
The preferences <CODE>merge</CODE> and <CODE>merge2</CODE> control how this
program is invoked. If a backup exists for this file (see the
<CODE>backup</CODE> preference), then the <CODE>merge</CODE> preference is used for
this purpose; otherwise <CODE>merge2</CODE> is used. In both cases, the
value of the preference should be a string representing the command
that should be passed to a shell to invoke the
merge program. Within this string, the special substrings
<CODE>CURRENT1</CODE>, <CODE>CURRENT2</CODE>, <CODE>NEW</CODE>, and <CODE>OLD</CODE> may appear
at any point. Unison will substitute these as follows before invoking
the command:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<CODE>CURRENT1</CODE> is replaced by the name of the local
copy of the file;
<LI CLASS="li-itemize"><CODE>CURRENT2</CODE> is replaced by the name of a temporary
file, into which the contents of the remote copy of the file have
been transferred by Unison prior to performing the merge;
<LI CLASS="li-itemize"><CODE>NEW</CODE> is replaced by the name of a temporary
file that Unison expects to be written by the merge program when
it finishes, giving the desired new contents of the file; and
<LI CLASS="li-itemize"><CODE>OLD</CODE> is replaced by the name of the backed up
copy of the original version of the file (i.e., its state at the
end of the last successful run of Unison), if one exists
(applies only to <CODE>merge</CODE>, not <CODE>merge2</CODE>).
</UL>
For example, on Unix systems setting the <CODE>merge</CODE> preference to
<PRE CLASS="verbatim">
merge = diff3 -m CURRENT1 OLD CURRENT2 &gt; NEW
</PRE>will tell Unison to use the external <CODE>diff3</CODE> program for merging. <BR>
<BR>
A large number of external merging programs are available. For
example, <CODE>emacs</CODE> users may find the following convenient:
<PRE CLASS="verbatim">
merge2 = emacs -q --eval '(ediff-merge-files "CURRENT1" "CURRENT2"
nil "NEW")'
merge = emacs -q --eval '(ediff-merge-files-with-ancestor
"CURRENT1" "CURRENT2" "OLD" nil "NEW")'
</PRE>(These commands are displayed here on two lines to avoid running off the
edge of the page. In your preference file, each should be written on a
single line.) <BR>
<BR>
<LI CLASS="li-itemize">If the external program exits without leaving any file at the
path <CODE>NEW</CODE>,
Unison considers the merge to have failed. If the merge program writes
a file called <CODE>NEW</CODE> but exits with a non-zero status code,
then Unison
considers the merge to have succeeded but to have generated conflicts.
In this case, it attempts to invoke an external editor so that the
user can resolve the conflicts. The value of the <CODE>editor</CODE>
preference controls what editor is invoked by Unison. The default
is <CODE>emacs</CODE>.<BR>
<BR>
<LI CLASS="li-itemize">Please send us suggestions for other useful values of the
<CODE>merge2</CODE> and <CODE>merge</CODE> preferences &ndash; we'd like to give several
examples in the manual.
</UL>
</UL><BR>
<BR>
<LI CLASS="li-itemize">Smaller changes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
When one preference file includes another, unison no longer adds the
suffix '<CODE>.prf</CODE>' to the included file by default. If a file with
precisely the given name exists in the .unison directory, it will be used;
otherwise Unison will
add <CODE>.prf</CODE>, as it did before. (This change means that included
preference files can be named <CODE>blah.include</CODE> instead of
<CODE>blah.prf</CODE>, so that unison will not offer them in its 'choose
a preference file' dialog.)
<LI CLASS="li-itemize">For Linux systems, we now offer both a statically linked and a dynamically
linked executable. The static one is larger, but will probably run on more
systems, since it doesn't depend on the same versions of dynamically
linked library modules being available.
<LI CLASS="li-itemize">Fixed the <CODE>force</CODE> and <CODE>prefer</CODE> preferences, which were
getting the propagation direction exactly backwards.
<LI CLASS="li-itemize">Fixed a bug in the startup code that would cause unison to crash
when the default profile (<CODE>~/.unison/default.prf</CODE>) does not exist.
<LI CLASS="li-itemize">Fixed a bug where, on the run when a profile is first created,
Unison would confusingly display the roots in reverse order in the user
interface.
</UL><BR>
<BR>
<LI CLASS="li-itemize">For developers:
<UL CLASS="itemize"><LI CLASS="li-itemize">
We've added a module dependency diagram to the source distribution, in
<CODE>src/DEPENDENCIES.ps</CODE>, to help new prospective developers with
navigating the code.
</UL>
</UL>
Changes since 2.6.11:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
Archive format has changed. <BR>
<BR>
<LI CLASS="li-itemize"><B>Incompatible change:</B>
The startup sequence has been completely rewritten
and greatly simplified. The main user-visible change is that the
<CODE>defaultpath</CODE> preference has been removed. Its effect can be
approximated by using multiple profiles, with <CODE>include</CODE> directives
to incorporate common settings. All uses of <CODE>defaultpath</CODE> in
existing profiles should be changed to <CODE>path</CODE>.<BR>
<BR>
Another change in startup behavior that will affect some users is that it
is no longer possible to specify roots <EM>both</EM> in the profile <EM>and</EM> on the command line.<BR>
<BR>
You can achieve a similar effect, though, by breaking your profile into
two:
<PRE CLASS="verbatim">
default.prf =
root = blah
root = foo
include common
common.prf =
&lt;everything else&gt;
</PRE>Now do
<PRE CLASS="verbatim">
unison common root1 root2
</PRE>when you want to specify roots explicitly.<BR>
<BR>
<LI CLASS="li-itemize">The <CODE>-prefer</CODE> and <CODE>-force</CODE> options have been extended to
allow users to specify that files with more recent modtimes should be
propagated, writing either <CODE>-prefer newer</CODE> or <CODE>-force newer</CODE>.
(For symmetry, Unison will also accept <CODE>-prefer older</CODE> or
<CODE>-force older</CODE>.) The <CODE>-force older/newer</CODE> options can only be
used when <CODE>-times</CODE> is also set.<BR>
<BR>
The graphical user interface provides access to these facilities on a
one-off basis via the <CODE>Actions</CODE> menu.<BR>
<BR>
<LI CLASS="li-itemize">Names of roots can now be &#8220;aliased&#8221; to allow replicas to be
relocated without changing the name of the archive file where Unison
stores information between runs. (This feature is for experts only. See
the &#8220;Archive Files&#8221; section of the manual for more information.)<BR>
<BR>
<LI CLASS="li-itemize">Graphical user-interface:
<UL CLASS="itemize"><LI CLASS="li-itemize">
A new command is provided in the Synchronization menu for
switching to a new profile without restarting Unison from scratch.
<LI CLASS="li-itemize">The GUI also supports one-key shortcuts for commonly
used profiles. If a profile contains a preference of the form
'<CODE>key = n</CODE>', where <CODE>n</CODE> is a single digit, then pressing this
key will cause Unison to immediately switch to this profile and begin
synchronization again from scratch. (Any actions that may have been
selected for a set of changes currently being displayed will be
discarded.) <BR>
<BR>
<LI CLASS="li-itemize">Each profile may include a preference '<CODE>label = &lt;string&gt;</CODE>' giving a
descriptive string that described the options selected in this profile.
The string is listed along with the profile name in the profile selection
dialog, and displayed in the top-right corner of the main Unison window.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Minor:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Fixed a bug that would sometimes cause the 'diff' display to order
the files backwards relative to the main user interface. (Thanks
to Pascal Brisset for this fix.)
<LI CLASS="li-itemize">On Unix systems, the graphical version of Unison will check the
<CODE>DISPLAY</CODE> variable and, if it is not set, automatically fall back
to the textual user interface.
<LI CLASS="li-itemize">Synchronization paths (<CODE>path</CODE> preferences) are now matched
against the ignore preferences. So if a path is both specified in a
<CODE>path</CODE> preference and ignored, it will be skipped.
<LI CLASS="li-itemize">Numerous other bugfixes and small improvements.
</UL>
</UL>
Changes since 2.6.1:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The synchronization of modification times has been disabled for
directories.<BR>
<BR>
<LI CLASS="li-itemize">Preference files may now include lines of the form
<CODE>include &lt;name&gt;</CODE>, which will cause <CODE>name.prf</CODE> to be read
at that point.<BR>
<BR>
<LI CLASS="li-itemize">The synchronization of permission between Windows and Unix now
works properly.<BR>
<BR>
<LI CLASS="li-itemize">A binding <CODE>CYGWIN=binmode</CODE> in now added to the environment
so that the Cygwin port of OpenSSH works properly in a non-Cygwin
context.<BR>
<BR>
<LI CLASS="li-itemize">The <CODE>servercmd</CODE> and <CODE>addversionno</CODE> preferences can now
be used together: <CODE>-addversionno</CODE> appends an appropriate
<CODE>-NNN</CODE> to the server command, which is found by using the value
of the <CODE>-servercmd</CODE> preference if there is one, or else just
<CODE>unison</CODE>.<BR>
<BR>
<LI CLASS="li-itemize">Both <CODE>'-pref=val'</CODE> and <CODE>'-pref val'</CODE> are now allowed for
boolean values. (The former can be used to set a preference to false.)<BR>
<BR>
<LI CLASS="li-itemize">Lot of small bugs fixed.
</UL>
Changes since 2.5.31:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The <CODE>log</CODE> preference is now set to <CODE>true</CODE> by default,
since the log file seems useful for most users.
<LI CLASS="li-itemize">Several miscellaneous bugfixes (most involving symlinks).
</UL>
Changes since 2.5.25:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
Archive format has changed (again). <BR>
<BR>
<LI CLASS="li-itemize">Several significant bugs introduced in 2.5.25 have been fixed.
</UL>
Changes since 2.5.1:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
Archive format has changed. Make sure you
synchronize your replicas before upgrading, to avoid spurious
conflicts. The first sync after upgrading will be slow.<BR>
<BR>
<LI CLASS="li-itemize">New functionality:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Unison now synchronizes file modtimes, user-ids, and group-ids. <BR>
<BR>
These new features are controlled by a set of new preferences, all of
which are currently <CODE>false</CODE> by default.
<UL CLASS="itemize"><LI CLASS="li-itemize">
When the <CODE>times</CODE> preference is set to <CODE>true</CODE>, file
modification times are propaged. (Because the representations of time
may not have the same granularity on both replicas, Unison may not always
be able to make the modtimes precisely equal, but it will get them as
close as the operating systems involved allow.)
<LI CLASS="li-itemize">When the <CODE>owner</CODE> preference is set to <CODE>true</CODE>, file
ownership information is synchronized.
<LI CLASS="li-itemize">When the <CODE>group</CODE> preference is set to <CODE>true</CODE>, group
information is synchronized.
<LI CLASS="li-itemize">When the <CODE>numericIds</CODE> preference is set to <CODE>true</CODE>, owner
and group information is synchronized numerically. By default, owner and
group numbers are converted to names on each replica and these names are
synchronized. (The special user id 0 and the special group 0 are never
mapped via user/group names even if this preference is not set.)
</UL><BR>
<BR>
<LI CLASS="li-itemize">Added an integer-valued preference <CODE>perms</CODE> that can be used to
control the propagation of permission bits. The value of this preference
is a mask indicating which permission bits should be synchronized. It is
set by default to 0<I>o</I>1777: all bits but the set-uid and set-gid bits are
synchronised (synchronizing theses latter bits can be a security hazard).
If you want to synchronize all bits, you can set the value of this
preference to &minus;1.<BR>
<BR>
<LI CLASS="li-itemize">Added a <CODE>log</CODE> preference (default <CODE>false</CODE>), which makes
Unison keep a complete record of the changes it makes to the replicas.
By default, this record is written to a file called <CODE>unison.log</CODE> in
the user's home directory (the value of the <CODE>HOME</CODE> environment
variable). If you want it someplace else, set the <CODE>logfile</CODE>
preference to the full pathname you want Unison to use.<BR>
<BR>
<LI CLASS="li-itemize">Added an <CODE>ignorenot</CODE> preference that maintains a set of patterns
for paths that should definitely <EM>not</EM> be ignored, whether or not
they match an <CODE>ignore</CODE> pattern. (That is, a path will now be ignored
iff it matches an ignore pattern and does not match any ignorenot patterns.)
</UL><BR>
<BR>
<LI CLASS="li-itemize">User-interface improvements:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Roots are now displayed in the user interface in the same order
as they were given on the command line or in the preferences file.
<LI CLASS="li-itemize">When the <CODE>batch</CODE> preference is set, the graphical user interface no
longer waits for user confirmation when it displays a warning message: it
simply pops up an advisory window with a Dismiss button at the bottom and
keeps on going.
<LI CLASS="li-itemize">Added a new preference for controlling how many status messages are
printed during update detection: <CODE>statusdepth</CODE> controls the maximum
depth for paths on the local machine (longer paths are not displayed, nor
are non-directory paths). The value should be an integer; default is 1.
<LI CLASS="li-itemize">Removed the <CODE>trace</CODE> and <CODE>silent</CODE> preferences. They did
not seem very useful, and there were too many preferences for controlling
output in various ways.
<LI CLASS="li-itemize">The text UI now displays just the default command (the one that
will be used if the user just types <CODE>&lt;return&gt;</CODE>) instead of all
available commands. Typing <CODE>?</CODE> will print the full list of
possibilities.
<LI CLASS="li-itemize">The function that finds the canonical hostname of the local host
(which is used, for example, in calculating the name of the archive file
used to remember which files have been synchronized) normally uses the
<CODE>gethostname</CODE> operating system call. However, if the environment
variable <CODE>UNISONLOCALHOSTNAME</CODE> is set, its value will now be used
instead. This makes it easier to use Unison in situations where a
machine's name changes frequently (e.g., because it is a laptop and gets
moved around a lot).
<LI CLASS="li-itemize">File owner and group are now displayed in the &#8220;detail window&#8221; at
the bottom of the screen, when unison is configured to synchronize them.
</UL><BR>
<BR>
<LI CLASS="li-itemize">For hackers:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Updated to Jacques Garrigue's new version of <CODE>lablgtk</CODE>, which
means we can throw away our local patched version. <BR>
<BR>
If you're compiling the GTK version of unison from sources, you'll need
to update your copy of lablgtk to the developers release.
(Warning: installing lablgtk under Windows is currently a bit
challenging.) <BR>
<BR>
<LI CLASS="li-itemize">The TODO.txt file (in the source distribution) has been cleaned up
and reorganized. The list of pending tasks should be much easier to
make sense of, for people that may want to contribute their programming
energies. There is also a separate file BUGS.txt for open bugs.
<LI CLASS="li-itemize">The Tk user interface has been removed (it was not being maintained
and no longer compiles).
<LI CLASS="li-itemize">The <CODE>debug</CODE> preference now prints quite a bit of additional
information that should be useful for identifying sources of problems.
<LI CLASS="li-itemize">The version number of the remote server is now checked right away
during the connection setup handshake, rather than later. (Somebody
sent a bug report of a server crash that turned out to come from using
inconsistent versions: better to check this earlier and in a way that
can't crash either client or server.)
<LI CLASS="li-itemize">Unison now runs correctly on 64-bit architectures (e.g. Alpha
linux). We will not be distributing binaries for these architectures
ourselves (at least for a while) but if someone would like to make them
available, we'll be glad to provide a link to them.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Bug fixes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Pattern matching (e.g. for <CODE>ignore</CODE>) is now case-insensitive
when Unison is in case-insensitive mode (i.e., when one of the replicas
is on a windows machine).
<LI CLASS="li-itemize">Some people had trouble with mysterious failures during
propagation of updates, where files would be falsely reported as having
changed during synchronization. This should be fixed.
<LI CLASS="li-itemize">Numerous smaller fixes.
</UL>
</UL>
Changes since 2.4.1:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Added a number of 'sorting modes' for the user interface. By
default, conflicting changes are displayed at the top, and the rest of
the entries are sorted in alphabetical order. This behavior can be
changed in the following ways:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Setting the <CODE>sortnewfirst</CODE> preference to <CODE>true</CODE> causes
newly created files to be displayed before changed files.
<LI CLASS="li-itemize">Setting <CODE>sortbysize</CODE> causes files to be displayed in
increasing order of size.
<LI CLASS="li-itemize">Giving the preference <CODE>sortfirst=&lt;pattern&gt;</CODE> (where
<CODE>&lt;pattern&gt;</CODE> is a path descriptor in the same format as 'ignore' and 'follow'
patterns, causes paths matching this pattern to be displayed first.
<LI CLASS="li-itemize">Similarly, giving the preference <CODE>sortlast=&lt;pattern&gt;</CODE>
causes paths matching this pattern to be displayed last.
</UL>
The sorting preferences are described in more detail in the user manual.
The <CODE>sortnewfirst</CODE> and <CODE>sortbysize</CODE> flags can also be accessed
from the 'Sort' menu in the grpahical user interface.<BR>
<BR>
<LI CLASS="li-itemize">Added two new preferences that can be used to change unison's
fundamental behavior to make it more like a mirroring tool instead of
a synchronizer.
<UL CLASS="itemize"><LI CLASS="li-itemize">
Giving the preference <CODE>prefer</CODE> with argument <CODE>&lt;root&gt;</CODE>
(by adding <CODE>-prefer &lt;root&gt;</CODE> to the command line or <CODE>prefer=&lt;root&gt;</CODE>)
to your profile) means that, if there is a conflict, the contents of
<CODE>&lt;root&gt;</CODE>
should be propagated to the other replica (with no questions asked).
Non-conflicting changes are treated as usual.
<LI CLASS="li-itemize">Giving the preference <CODE>force</CODE> with argument <CODE>&lt;root&gt;</CODE>
will make unison resolve <EM>all</EM> differences in favor of the given
root, even if it was the other replica that was changed.
</UL>
These options should be used with care! (More information is available in
the manual.)<BR>
<BR>
<LI CLASS="li-itemize">Small changes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Changed default answer to 'Yes' in all two-button dialogs in the
graphical interface (this seems more intuitive).<BR>
<BR>
<LI CLASS="li-itemize">The <CODE>rsync</CODE> preference has been removed (it was used to
activate rsync compression for file transfers, but rsync compression is
now enabled by default).
<LI CLASS="li-itemize">In the text user interface, the arrows indicating which direction
changes are being
propagated are printed differently when the user has overridded Unison's
default recommendation (<CODE>====&gt;</CODE> instead of <CODE>----&gt;</CODE>). This
matches the behavior of the graphical interface, which displays such
arrows in a different color.
<LI CLASS="li-itemize">Carriage returns (Control-M's) are ignored at the ends of lines in
profiles, for Windows compatibility.
<LI CLASS="li-itemize">All preferences are now fully documented in the user manual.
</UL>
</UL>
Changes since 2.3.12:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
Archive format has changed. Make sure you
synchronize your replicas before upgrading, to avoid spurious
conflicts. The first sync after upgrading will be slow.<BR>
<BR>
<LI CLASS="li-itemize">New/improved functionality:
<UL CLASS="itemize"><LI CLASS="li-itemize">
A new preference -sortbysize controls the order in which changes
are displayed to the user: when it is set to true, the smallest
changed files are displayed first. (The default setting is false.)
<LI CLASS="li-itemize">A new preference -sortnewfirst causes newly created files to be
listed before other updates in the user interface.
<LI CLASS="li-itemize">We now allow the ssh protocol to specify a port.
<LI CLASS="li-itemize">Incompatible change: The unison: protocol is deprecated, and we added
file: and socket:. You may have to modify your profiles in the
.unison directory.
If a replica is specified without an explicit protocol, we now
assume it refers to a file. (Previously "//saul/foo" meant to use
SSH to connect to saul, then access the foo directory. Now it means
to access saul via a remote file mechanism such as samba; the old
effect is now achieved by writing <TT>ssh://saul/foo</TT>.)
<LI CLASS="li-itemize">Changed the startup sequence for the case where roots are given but
no profile is given on the command line. The new behavior is to
use the default profile (creating it if it does not exist), and
temporarily override its roots. The manual claimed that this case
would work by reading no profile at all, but AFAIK this was never
true.
<LI CLASS="li-itemize">In all user interfaces, files with conflicts are always listed first
<LI CLASS="li-itemize">A new preference 'sshversion' can be used to control which version
of ssh should be used to connect to the server. Legal values are 1 and 2.
(Default is empty, which will make unison use whatever version of ssh
is installed as the default 'ssh' command.)
<LI CLASS="li-itemize">The situation when the permissions of a file was updated the same on
both side is now handled correctly (we used to report a spurious conflict)</UL><BR>
<BR>
<LI CLASS="li-itemize">Improvements for the Windows version:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The fact that filenames are treated case-insensitively under
Windows should now be handled correctly. The exact behavior is described
in the cross-platform section of the manual.
<LI CLASS="li-itemize">It should be possible to synchronize with Windows shares, e.g.,
//host/drive/path.
<LI CLASS="li-itemize">Workarounds to the bug in syncing root directories in Windows.
The most difficult thing to fix is an ocaml bug: Unix.opendir fails on
c: in some versions of Windows.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Improvements to the GTK user interface (the Tk interface is no
longer being maintained):
<UL CLASS="itemize"><LI CLASS="li-itemize">
The UI now displays actions differently (in blue) when they have been
explicitly changed by the user from Unison's default recommendation.
<LI CLASS="li-itemize">More colorful appearance.
<LI CLASS="li-itemize">The initial profile selection window works better.
<LI CLASS="li-itemize">If any transfers failed, a message to this effect is displayed along with
'Synchronization complete' at the end of the transfer phase (in case they
may have scrolled off the top).
<LI CLASS="li-itemize">Added a global progress meter, displaying the percentage of <EM>total</EM>
bytes that have been transferred so far.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Improvements to the text user interface:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The file details will be displayed automatically when a
conflict is been detected.
<LI CLASS="li-itemize">when a warning is generated (e.g. for a temporary
file left over from a previous run of unison) Unison will no longer
wait for a response if it is running in -batch mode.
<LI CLASS="li-itemize">The UI now displays a short list of possible inputs each time it waits
for user interaction.
<LI CLASS="li-itemize">The UI now quits immediately (rather than looping back and starting
the interaction again) if the user presses 'q' when asked whether to
propagate changes.
<LI CLASS="li-itemize">Pressing 'g' in the text user interface will proceed immediately
with propagating updates, without asking any more questions.
</UL><BR>
<BR>
<LI CLASS="li-itemize">Documentation and installation changes:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The manual now includes a FAQ, plus sections on common problems and
on tricks contributed by users.
<LI CLASS="li-itemize">Both the download page and the download directory explicitly say
what are the current stable and beta-test version numbers.
<LI CLASS="li-itemize">The OCaml sources for the up-to-the-minute developers' version (not
guaranteed to be stable, or even to compile, at any given time!) are now
available from the download page.
<LI CLASS="li-itemize">Added a subsection to the manual describing cross-platform
issues (case conflicts, illegal filenames)
</UL><BR>
<BR>
<LI CLASS="li-itemize">Many small bug fixes and random improvements.<BR>
<BR>
</UL>
Changes since 2.3.1:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Several bug fixes. The most important is a bug in the rsync
module that would occasionally cause change propagation to fail with a
'rename' error.
</UL>
Changes since 2.2:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The multi-threaded transport system is now disabled by default.
(It is not stable enough yet.)
<LI CLASS="li-itemize">Various bug fixes.
<LI CLASS="li-itemize">A new experimental feature: <BR>
<BR>
The final component of a -path argument may now be the wildcard
specifier <CODE>*</CODE>. When Unison sees such a path, it expands this path on
the client into into the corresponding list of paths by listing the
contents of that directory. <BR>
<BR>
Note that if you use wildcard paths from the command line, you will
probably need to use quotes or a backslash to prevent the * from
being interpreted by your shell.<BR>
<BR>
If both roots are local, the contents of the first one will be used
for expanding wildcard paths. (Nb: this is the first one <EM>after</EM> the
canonization step &ndash; i.e., the one that is listed first in the user
interface &ndash; not the one listed first on the command line or in the
preferences file.)
</UL>
Changes since 2.1:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The transport subsystem now includes an implementation by
Sylvain Gommier and Norman Ramsey of Tridgell and Mackerras's
<CODE>rsync</CODE> protocol. This protocol achieves much faster
transfers when only a small part of a large file has been changed by
sending just diffs. This feature is mainly helpful for transfers over
slow links&mdash;on fast local area networks it can actually degrade
performance&mdash;so we have left it off by default. Start unison with
the <CODE>-rsync</CODE> option (or put <CODE>rsync=true</CODE> in your preferences
file) to turn it on.<BR>
<BR>
<LI CLASS="li-itemize">&#8220;Progress bars&#8221; are now diplayed during remote file transfers,
showing what percentage of each file has been transferred so far.<BR>
<BR>
<LI CLASS="li-itemize">The version numbering scheme has changed. New releases will now
be have numbers like 2.2.30, where the second component is
incremented on every significant public release and the third
component is the &#8220;patch level.&#8221;<BR>
<BR>
<LI CLASS="li-itemize">Miscellaneous improvements to the GTK-based user interface.
<LI CLASS="li-itemize">The manual is now available in PDF format.<BR>
<BR>
<LI CLASS="li-itemize">We are experimenting with using a multi-threaded transport
subsystem to transfer several files at the same time, making
much more effective use of available network bandwidth. This feature
is not completely stable yet, so by default it is disabled in the
release version of Unison.<BR>
<BR>
If you want to play with the multi-threaded version, you'll need to
recompile Unison from sources (as described in the documentation),
setting the THREADS flag in Makefile.OCaml to true. Make sure that
your OCaml compiler has been installed with the <CODE>-with-pthreads</CODE>
configuration option. (You can verify this by checking whether the
file <CODE>threads/threads.cma</CODE> in the OCaml standard library
directory contains the string <CODE>-lpthread</CODE> near the end.)
</UL>
Changes since 1.292:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Reduced memory footprint (this is especially important during
the first run of unison, where it has to gather information about all
the files in both repositories).
<LI CLASS="li-itemize">Fixed a bug that would cause the socket server under NT to fail
after the client exits.
<LI CLASS="li-itemize">Added a SHIFT modifier to the Ignore menu shortcut keys in GTK
interface (to avoid hitting them accidentally).
</UL>
Changes since 1.231:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Tunneling over ssh is now supported in the Windows version. See
the installation section of the manual for detailed instructions.<BR>
<BR>
<LI CLASS="li-itemize">The transport subsystem now includes an implementation of the
<CODE>rsync</CODE> protocol, built by Sylvain Gommier and Norman Ramsey.
This protocol achieves much faster transfers when only a small part of
a large file has been changed by sending just diffs. The rsync
feature is off by default in the current version. Use the
<CODE>-rsync</CODE> switch to turn it on. (Nb. We still have a lot of
tuning to do: you may not notice much speedup yet.)<BR>
<BR>
<LI CLASS="li-itemize">We're experimenting with a multi-threaded transport subsystem,
written by Jerome Vouillon. The downloadable binaries are still
single-threaded: if you want to try the multi-threaded version, you'll
need to recompile from sources. (Say <CODE>make THREADS=true</CODE>.)
Native thread support from the compiler is required. Use the option
<CODE>-threads N</CODE> to select the maximal number of concurrent
threads (default is 5). Multi-threaded
and single-threaded clients/servers can interoperate. <BR>
<BR>
<LI CLASS="li-itemize">A new GTK-based user interface is now available, thanks to
Jacques Garrigue. The Tk user interface still works, but we'll be
shifting development effort to the GTK interface from now on.
<LI CLASS="li-itemize">OCaml 3.00 is now required for compiling Unison from sources.
The modules <CODE>uitk</CODE> and <CODE>myfileselect</CODE> have been changed to
use labltk instead of camltk. To compile the Tk interface in Windows,
you must have ocaml-3.00 and tk8.3. When installing tk8.3, put it in
<CODE>c:\Tcl</CODE> rather than the suggested <CODE>c:\Program Files\Tcl</CODE>,
and be sure to install the headers and libraries (which are not
installed by default).<BR>
<BR>
<LI CLASS="li-itemize">Added a new <CODE>-addversionno</CODE> switch, which causes unison to
use <CODE>unison-&lt;currentversionnumber&gt;</CODE> instead of just <CODE>unison</CODE>
as the remote server command. This allows multiple versions of unison
to coexist conveniently on the same server: whichever version is run
on the client, the same version will be selected on the server.
</UL>
Changes since 1.219:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
Archive format has changed. Make sure you
synchronize your replicas before upgrading, to avoid spurious
conflicts. The first sync after upgrading will be slow.<BR>
<BR>
<LI CLASS="li-itemize">This version fixes several annoying bugs, including:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Some cases where propagation of file permissions was not
working.
<LI CLASS="li-itemize">umask is now ignored when creating directories
<LI CLASS="li-itemize">directories are create writable, so that a read-only directory and
its contents can be propagated.
<LI CLASS="li-itemize">Handling of warnings generated by the server.
<LI CLASS="li-itemize">Synchronizing a path whose parent is not a directory on both sides is
now flagged as erroneous.
<LI CLASS="li-itemize">Fixed some bugs related to symnbolic links and nonexistant roots.
<UL CLASS="itemize"><LI CLASS="li-itemize">
When a change (deletion or new contents) is propagated onto a
'follow'ed symlink, the file pointed to by the link is now changed.
(We used to change the link itself, which doesn't fit our assertion
that 'follow' means the link is completely invisible)
<LI CLASS="li-itemize">When one root did not exist, propagating the other root on top of it
used to fail, becuase unison could not calculate the working directory
into which to write changes. This should be fixed.
</UL>
</UL><BR>
<BR>
<LI CLASS="li-itemize">A human-readable timestamp has been added to Unison's archive files.<BR>
<BR>
<LI CLASS="li-itemize">The semantics of Path and Name regular expressions now
correspond better. <BR>
<BR>
<LI CLASS="li-itemize">Some minor improvements to the text UI (e.g. a command for going
back to previous items)<BR>
<BR>
<LI CLASS="li-itemize">The organization of the export directory has changed &mdash; should
be easier to find / download things now.
</UL>
Changes since 1.200:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
Archive format has changed. Make sure you
synchronize your replicas before upgrading, to avoid spurious
conflicts. The first sync after upgrading will be slow.<BR>
<BR>
<LI CLASS="li-itemize">This version has not been tested extensively on Windows.<BR>
<BR>
<LI CLASS="li-itemize">Major internal changes designed to make unison safer to run
at the same time as the replicas are being changed by the user.<BR>
<BR>
<LI CLASS="li-itemize">Internal performance improvements.
</UL>
Changes since 1.190:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
Archive format has changed. Make sure you
synchronize your replicas before upgrading, to avoid spurious
conflicts. The first sync after upgrading will be slow.<BR>
<BR>
<LI CLASS="li-itemize">A number of internal functions have been changed to reduce the
amount of memory allocation, especially during the first
synchronization. This should help power users with very big replicas.<BR>
<BR>
<LI CLASS="li-itemize">Reimplementation of low-level remote procedure call stuff, in
preparation for adding rsync-like smart file transfer in a later
release. <BR>
<BR>
<LI CLASS="li-itemize">Miscellaneous bug fixes.
</UL>
Changes since 1.180:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
Archive format has changed. Make sure you
synchronize your replicas before upgrading, to avoid spurious
conflicts. The first sync after upgrading will be slow.<BR>
<BR>
<LI CLASS="li-itemize">Fixed some small bugs in the interpretation of ignore patterns. <BR>
<BR>
<LI CLASS="li-itemize">Fixed some problems that were preventing the Windows version
from working correctly when click-started.<BR>
<BR>
<LI CLASS="li-itemize">Fixes to treatment of file permissions under Windows, which were
causing spurious reports of different permissions when synchronizing
between windows and unix systems.<BR>
<BR>
<LI CLASS="li-itemize">Fixed one more non-tail-recursive list processing function,
which was causing stack overflows when synchronizing very large
replicas.
</UL>
Changes since 1.169:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The text user interface now provides commands for ignoring
files.
<LI CLASS="li-itemize">We found and fixed some <EM>more</EM> non-tail-recursive list
processing functions. Some power users have reported success with
very large replicas.
<LI CLASS="li-itemize"><B>Incompatible change:</B>
Files ending in <CODE>.tmp</CODE> are no longer ignored automatically. If you want
to ignore such files, put an appropriate ignore pattern in your profile.<BR>
<BR>
<LI CLASS="li-itemize"><B>Incompatible change:</B>
The syntax of <TT>ignore</TT> and <TT>follow</TT>
patterns has changed. Instead of putting a line of the form
<PRE CLASS="verbatim">
ignore = &lt;regexp&gt;
</PRE>in your profile (<TT>.unison/default.prf</TT>), you should put:
<PRE CLASS="verbatim">
ignore = Regexp &lt;regexp&gt;
</PRE>Moreover, two other styles of pattern are also recognized:
<PRE CLASS="verbatim">
ignore = Name &lt;name&gt;
</PRE>matches any path in which one component matches <CODE>&lt;name&gt;</CODE>, while
<PRE CLASS="verbatim">
ignore = Path &lt;path&gt;
</PRE>matches exactly the path <CODE>&lt;path&gt;</CODE>.<BR>
<BR>
Standard &#8220;globbing&#8221; conventions can be used in <CODE>&lt;name&gt;</CODE> and
<CODE>&lt;path&gt;</CODE>:
<UL CLASS="itemize"><LI CLASS="li-itemize">
a <CODE>?</CODE> matches any single character except <CODE>/</CODE>
<LI CLASS="li-itemize">a <CODE>*</CODE> matches any sequence of characters not including <CODE>/</CODE>
<LI CLASS="li-itemize"><CODE>[xyz]</CODE> matches any character from the set {<TT><I>x</I></TT>,
<TT><I>y</I></TT>, <TT><I>z</I></TT> }
<LI CLASS="li-itemize"><CODE>{a,bb,ccc}</CODE> matches any one of <CODE>a</CODE>, <CODE>bb</CODE>, or
<CODE>ccc</CODE>.
</UL><BR>
See the user manual for some examples.
</UL>
Changes since 1.146:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Some users were reporting stack overflows when synchronizing
huge directories. We found and fixed some non-tail-recursive list
processing functions, which we hope will solve the problem. Please
give it a try and let us know.
<LI CLASS="li-itemize">Major additions to the documentation.
</UL>
Changes since 1.142:
<UL CLASS="itemize"><LI CLASS="li-itemize">
Major internal tidying and many small bugfixes.
<LI CLASS="li-itemize">Major additions to the user manual.
<LI CLASS="li-itemize">Unison can now be started with no arguments &ndash; it will prompt
automatically for the name of a profile file containing the roots to
be synchronized. This makes it possible to start the graphical UI
from a desktop icon.
<LI CLASS="li-itemize">Fixed a small bug where the text UI on NT was raising a 'no such
signal' exception.
</UL>
Changes since 1.139:
<UL CLASS="itemize"><LI CLASS="li-itemize">
The precompiled windows binary in the last release was compiled
with an old OCaml compiler, causing propagation of permissions not to
work (and perhaps leading to some other strange behaviors we've heard
reports about). This has been corrected. If you're using precompiled
binaries on Windows, please upgrade.
<LI CLASS="li-itemize">Added a <CODE>-debug</CODE> command line flag, which controls debugging
of various modules. Say <CODE>-debug XXX</CODE> to enable debug tracing for
module <CODE>XXX</CODE>, or <CODE>-debug all</CODE> to turn on absolutely everything.
<LI CLASS="li-itemize">Fixed a small bug where the text UI on NT was raising a 'no such signal'
exception.
</UL>
Changes since 1.111:
<UL CLASS="itemize"><LI CLASS="li-itemize">
<B>Incompatible change:</B>
The names and formats of the preference files in
the .unison directory have changed. In particular:
<UL CLASS="itemize"><LI CLASS="li-itemize">
the file &#8220;prefs&#8221; should be renamed to default.prf
<LI CLASS="li-itemize">the contents of the file &#8220;ignore&#8221; should be merged into
default.prf. Each line of the form <CODE>REGEXP</CODE> in ignore should
become a line of the form <CODE>ignore = REGEXP</CODE> in default.prf.
</UL>
<LI CLASS="li-itemize">Unison now handles permission bits and symbolic links. See the
manual for details.<BR>
<BR>
<LI CLASS="li-itemize">You can now have different preference files in your .unison
directory. If you start unison like this
<PRE CLASS="verbatim">
unison profilename
</PRE>(i.e. with just one &#8220;anonymous&#8221; command-line argument), then the
file <CODE>~/.unison/profilename.prf</CODE> will be loaded instead of
<CODE>default.prf</CODE>. <BR>
<BR>
<LI CLASS="li-itemize">Some improvements to terminal handling in the text user interface<BR>
<BR>
<LI CLASS="li-itemize">Added a switch -killServer that terminates the remote server process
when the unison client is shutting down, even when using sockets for
communication. (By default, a remote server created using ssh/rsh is
terminated automatically, while a socket server is left running.)
<LI CLASS="li-itemize">When started in 'socket server' mode, unison prints 'server started' on
stderr when it is ready to accept connections.
(This may be useful for scripts that want to tell when a socket-mode server
has finished initalization.)
<LI CLASS="li-itemize">We now make a nightly mirror of our current internal development
tree, in case anyone wants an up-to-the-minute version to hack
around with.
<LI CLASS="li-itemize">Added a file CONTRIB with some suggestions for how to help us
make Unison better.
</UL>
</div><BR>
<BR>
<!--HTMLFOOT-->
<!--ENDHTML-->
<!--FOOTER-->
<HR SIZE=2><BLOCKQUOTE CLASS="quote"><EM>This document was translated from L<sup>A</sup>T<sub>E</sub>X by
</EM><A HREF="http://pauillac.inria.fr/~maranget/hevea/index.html"><EM>H<FONT SIZE=2><sup>E</sup></FONT>V<FONT SIZE=2><sup>E</sup></FONT>A</EM></A><EM>.</EM></BLOCKQUOTE></BODY>
</HTML>
Reference in New Issue View Git Blame Copy Permalink