From 1f6f142cf1706d56310c1615e05cd046b65ea1148700e6b60e4988de97c03bfe Mon Sep 17 00:00:00 2001 From: OBS User unknown Date: Mon, 15 Jan 2007 23:40:09 +0000 Subject: [PATCH] OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/unison?expand=0&rev=1 --- .gitattributes | 23 + .gitignore | 1 + ready | 0 unison-2.17.1-manual.html | 3989 +++++++++++++++++++++++++++++++++++++ unison-2.17.1.tar.gz | 3 + unison-windowout.diff | 57 + unison.changes | 105 + unison.desktop | 5 + unison.spec | 122 ++ 9 files changed, 4305 insertions(+) create mode 100644 .gitattributes create mode 100644 .gitignore create mode 100644 ready create mode 100644 unison-2.17.1-manual.html create mode 100644 unison-2.17.1.tar.gz create mode 100644 unison-windowout.diff create mode 100644 unison.changes create mode 100644 unison.desktop create mode 100644 unison.spec diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..9b03811 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,23 @@ +## Default LFS +*.7z filter=lfs diff=lfs merge=lfs -text +*.bsp filter=lfs diff=lfs merge=lfs -text +*.bz2 filter=lfs diff=lfs merge=lfs -text +*.gem filter=lfs diff=lfs merge=lfs -text +*.gz filter=lfs diff=lfs merge=lfs -text +*.jar filter=lfs diff=lfs merge=lfs -text +*.lz filter=lfs diff=lfs merge=lfs -text +*.lzma filter=lfs diff=lfs merge=lfs -text +*.obscpio filter=lfs diff=lfs merge=lfs -text +*.oxt filter=lfs diff=lfs merge=lfs -text +*.pdf filter=lfs diff=lfs merge=lfs -text +*.png filter=lfs diff=lfs merge=lfs -text +*.rpm filter=lfs diff=lfs merge=lfs -text +*.tbz filter=lfs diff=lfs merge=lfs -text +*.tbz2 filter=lfs diff=lfs merge=lfs -text +*.tgz filter=lfs diff=lfs merge=lfs -text +*.ttf filter=lfs diff=lfs merge=lfs -text +*.txz filter=lfs diff=lfs merge=lfs -text +*.whl filter=lfs diff=lfs merge=lfs -text +*.xz filter=lfs diff=lfs merge=lfs -text +*.zip filter=lfs diff=lfs merge=lfs -text +*.zst filter=lfs diff=lfs merge=lfs -text diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..57affb6 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.osc diff --git a/ready b/ready new file mode 100644 index 0000000..473a0f4 diff --git a/unison-2.17.1-manual.html b/unison-2.17.1-manual.html new file mode 100644 index 0000000..6d9fbb8 --- /dev/null +++ b/unison-2.17.1-manual.html @@ -0,0 +1,3989 @@ + + + + + + + + + + + + + + + + + + + + + +
+
+

+
+
Unison File Synchronizer
+User Manual and Reference Guide
+Version 2.17.1
+

+
+ + +

Contents

+ +
+ Preface
+          •People
+          •Mailing Lists and Bug Reporting
+          •Development Status
+          •Copying
+          •Acknowledgements
+Installation
+          •Downloading Unison
+          •Running Unison
+          •Upgrading
+          •Building Unison from Scratch
+                  Unix
+                  Windows
+                  Installation Options
+Tutorial
+          •Preliminaries
+          •Local Usage
+          •Remote Usage
+          •Remote Shell Method
+          •Socket Method
+          •Using Unison for All Your Files
+          •Using Unison to Synchronize More Than Two Machines
+          •Going Further
+Basic Concepts
+          •Roots
+          •Paths
+          •What is an Update?
+          •What is a Conflict?
+          •Reconciliation
+          •Invariants
+          •Caveats and Shortcomings
+Reference Guide
+          •Running Unison
+          •The .unison Directory
+          •Archive Files
+          •Preferences
+          •Profiles
+          •Sample Profiles
+                  A Minimal Profile
+                  A Basic Profile
+                  A Power-User Profile
+          •Keeping Backups
+          •Merging Conflicting Versions
+          •The User Interface
+          •Exit code
+          •Path specification
+          •Ignoring Paths
+          •Symbolic Links
+          •Permissions
+          •Cross-Platform Synchronization
+          •Slow Links
+          •Fast Update Detection
+          •Click-starting Unison
+Installing Ssh
+          •Unix
+          •Windows
+Changes in Version 2.17.1
+ +
+ +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.
+
+Unison +shares a number of features with tools such as configuration +management packages (CVS, +PRCS, +etc.), +distributed filesystems +(Coda, +etc.), +uni-directional mirroring utilities +(rsync, +etc.), +and other synchronizers +(Intellisync, +Reconcile, +etc). +However, there are several points where it differs: + +
+ +

Preface

+ + + +

People

+ +Benjamin Pierce leads the +Unison project. +The current version of Unison was designed and implemented by + Trevor Jim, + Benjamin Pierce, +and + Jérôme Vouillon, +with + Alan Schmitt, + Malo Denielou, + Zhe Yang, + Sylvain Gommier, and + Matthieu Goulay. +Our implementation of the + rsync + protocol was built by + Norman Ramsey + and Sylvain Gommier. It is is based on + Andrew Tridgell's + thesis work + and inspired by his + rsync + utility. +The mirroring and merging functionality was implemented by + Sylvain Roy and improved by Malo Denielou. +Jacques Garrigue + 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. +Insik Shin +and +Insup Lee contributed design +ideas to this implementation. +Cedric Fournet +contributed to an even earlier prototype.
+
+ + +

Mailing Lists and Bug Reporting

+ + + +
Mailing Lists:
+ +Moderated mailing lists are available for bug reporting, announcements +of new versions, discussions among users, and discussions among +developers. See +http://www.cis.upenn.edu/~bcpierce/unison/lists.html for more +information.
+
+ + +

Development Status

+ +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 +http://www.cis.upenn.edu/~bcpierce/harmony.) +At this point, there is no one whose job it is to maintain Unison, +fix bugs, or answer questions.
+
+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.
+
+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 +unison-users@yahoogroups.com.
+
+Feature requests are welcome, but will probably just be added to the +ever-growing todo list. They should also be sent to unison-users@yahoogroups.com.
+
+Patches are even more welcome. They should be sent to +unison-hackers@yahoogroups.com. +(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 CONTRIB.
+
+ + +

Copying

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

Acknowledgements

+ +Work on Unison has been supported by the National Science Foundation +under grants CCR-9701826 and ITR-0113226, Principles and Practice of + Synchronization, and by University of Pennsylvania's Institute for +Research in Cognitive Science (IRCS).
+
+
+ +

Installation

+ +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 +Frequently Asked +Questions page helpful. Pre-built binaries are available for a +variety of platforms.
+
+Unison can be used with either of two user interfaces: +
  1. +a simple textual interface, suitable for dumb terminals (and +running from scripts), and +
  2. a more sophisticated grapical interface, based on Gtk2. +
+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 client +machine). Other machines that you synchronize with can get along just +fine with the textual version.
+
+ + +

Downloading Unison

+ +The Unison download site lives under +http://www.cis.upenn.edu/~bcpierce/unison.
+
+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).
+
+The executable file for the graphical version (with a name including +gtkui) actually provides both interfaces: the graphical one +appears by default, while the textual interface can be selected by including +-ui text on the command line. The textui executable +provides just the textual interface.
+
+If you don't see a pre-built executable for your architecture, you'll +need to build it yourself. See the Building Unison section. +There are also a small number of contributed ports to other +architectures that are not maintained by us. See the +Contributed +Ports page to check what's available.
+
+Check to make sure that what you have downloaded is really executable. +Either click-start it, or type unison -version at the command +line.
+
+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 ssh for authentication and secure +transfer. If you intend to use the last option, you may need to install +ssh; see the Installing Ssh section.
+
+ + +

Running Unison

+ +Once you've got Unison installed on at least one system, read +the Tutorial section of the user manual (or type unison -doc + tutorial) for instructions on how to get started.
+
+ + +

Upgrading

+ +Upgrading to a new version of Unison is as simple as throwing away the old +binary and installing the new one.
+
+Before upgrading, it is a good idea to run the old 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 — 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.
+
+ + +

Building Unison from Scratch

+ +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.
+
+In principle, Unison should work on any platform to which OCaml has been +ported and on which the Unix 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.
+
+ + +

Unix

+ +You'll need the Objective Caml compiler (version 3.07 or later), which is +available from http://caml.inria.fr. 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 make world opt, +then su to root and do make install.)
+
+You'll also need the GNU make utility, standard on many Unix +systems. (Type make –version to check that you've got the +GNU version.)
+
+Once you've got OCaml installed, grab a copy of the Unison sources, +unzip and untar them, change to the new unison directory, and +type “make UISTYLE=text.” +The result should be an executable file called unison. +Type ./unison to make sure the program is executable. You +should get back a usage message.
+
+If you want to build the graphical user interface, you will need to install +two additional things: + +Now build unison. If your search paths are set up correctly, simply typing +make +again should build a unison executable with a Gtk2 graphical +interface. (In previous releases of Unison, it was necessary to add UISTYLE=gtk2 to the 'make' command above. This requirement has been +removed: the makefile should detect automatically when lablgtk2 is +present and set this flag automatically.)
+
+Put the unison 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.
+
+ + +

Windows

+ +Although the binary distribution should work on any version of Windows, +some people may want to build Unison from scratch on those systems too.
+
+ + +
Bytecode version:
+ 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 http://caml.inria.fr). Then grab a copy +of Unison sources and type +
+       make NATIVE=false
+
to compile the bytecode. The result should be an executable file called +unison.exe.
+
+ + +
Native version:
+ Building a more efficient, native version of +Unison on Windows requires a little more work. See the file INSTALL.win32 in the source code distribution.
+
+ + +

Installation Options

+ +The Makefile in the distribution includes several switches that +can be used to control how Unison is built. Here are the most useful +ones: + + +
+ +

Tutorial

+ + + +

Preliminaries

+ +Unison can be used with either of two user interfaces: +
  1. +a straightforward textual interface and +
  2. a more sophisticated graphical interface +
+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 unison +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 -ui text. +The other command-line arguments to both versions are identical.
+
+The graphical version can also be run directly by clicking on its icon, but +this may require a little set-up (see the Click-starting + Unison section). For this tutorial, we assume that you're starting it from the +command line.
+
+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 client. If +you're synchronizing two machines, let's call them client and +server.
+
+ + +

Local Usage

+ +Let's get the client machine set up first and see how to synchronize +two directories on a single machine.
+
+Follow the instructions in the Installation 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—or if you will use both interfaces [the gtkui +binary actually has both compiled in]—then download the gtkui binary.)
+
+Create a small test directory a.tmp containing a couple of files +and/or subdirectories, e.g., +
+       mkdir a.tmp
+       touch a.tmp/a a.tmp/b
+       mkdir a.tmp/d
+       touch a.tmp/d/f
+
Copy this directory to b.tmp: +
+       cp -r a.tmp b.tmp
+
+Now try synchronizing a.tmp and b.tmp. (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: +
+       unison a.tmp b.tmp
+
+
+Textual Interface: +
+Graphical Interface: +Next, make some changes in a.tmp and/or b.tmp. For example: +
+        rm a.tmp/a
+        echo "Hello" > a.tmp/b
+        echo "Hello" > b.tmp/b
+        date > b.tmp/c
+        echo "Hi there" > a.tmp/d/h
+        echo "Hello there" > b.tmp/d/h
+
Run Unison again: +
+       unison a.tmp b.tmp
+
+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, +
+                 <---  new file   c  [f]
+
indicates that the file c 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 follw Unison's recommendation, +press the “f” at the prompt.
+
+If both replicas are modified and their contents are different, then +the changes are in conflict: <-?-> is displayed to indicate +that Unison needs guidance on which replica should override the +other. +
+     new file  <-?->  new file   d/h  []
+
By default, neither version will be propagated and both +replicas will remain as they are.
+
+If both replicas have been modified but their new contents are the same +(as with the file b), then no propagation is necessary and +nothing is shown. Unison simply notes that the file is up to date.
+
+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.
+
+
+Textual Interface: +
+Graphical Interface: + + +

Remote Usage

+ +Next, we'll get Unison set up to synchronize replicas on two different +machines.
+
+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.)
+
+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 -addversionno option; see +the Preferences section.
+
+Now there is a decision to be made. Unison provides two methods for +communicating between the client and the server: + +Decide which of these you want to try, and continue with +the Remote Shell Method section or +the Socket Method section, as appropriate.
+
+ + +

Remote Shell Method

+ +The standard remote shell facility on Unix systems is ssh, which provides the +same functionality as the older rsh but much better security. Ssh is available from +ftp://ftp.cs.hut.fi/pub/ssh/; up-to-date binaries for some +architectures can also be found at +ftp://ftp.faqs.org/ssh/contrib. See section A.2 +for installation instructions for the Windows version.
+
+Running +ssh 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 ssh documentation +for information on how to set this up. The examples in this section +use ssh, but you can substitute rsh for ssh if +you wish.
+
+First, test that we can invoke Unison on the server from the client. +Typing +
+        ssh remotehostname unison -version
+
+should print the same version information as running +
+        unison -version
+
locally on the client. If remote execution fails, then either +something is wrong with your ssh setup (e.g., “permission denied”) +or else the search path that's being used when executing commands on +the server doesn't contain the unison executable (e.g., +“command not found”).
+
+Create a test directory a.tmp in your home directory on the client +machine.
+
+Test that the local unison client can start and connect to the +remote server. Type +
+          unison -testServer a.tmp ssh://remotehostname/a.tmp
+
+Now cd to your home directory and type: +
+          unison a.tmp ssh://remotehostname/a.tmp
+
The result should be that the entire directory a.tmp is propagated +from the client to your home directory on the server.
+
+After finishing the first synchronization, change a few files and try +synchronizing again. You should see similar results as in the local +case.
+
+If your user name on the server is not the same as on the client, you +need to specify it on the command line: +
+          unison a.tmp ssh://username@remotehostname/a.tmp
+
+Notes: + + + +

Socket Method

+ +
+ Warning: 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 ssh method. +
+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.
+
+To start the daemon, type +
+       unison -socket NNNN
+
on the server machine, where NNNN is the socket number that the +daemon should listen on for connections from clients. (NNNN can +be any large number that is not being used by some other program; if +NNNN 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.
+
+Create a test directory a.tmp in your home directory on the +client machine. Now type: +
+       unison a.tmp socket://remotehostname:NNNN/a.tmp
+
+The result should be that the entire directory a.tmp is +propagated from the client to the server (a.tmp 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.
+
+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.
+
+ + +

Using Unison for All Your Files

+ +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: +
  1. +Synchronize your whole home directory, using the Ignore facility +(see the Ignore section) +to avoid synchronizing temporary files and things that only belong on +one host. +
  2. Create a subdirectory called shared (or current, or +whatever) in your home directory on each host, and put all the files +you want to synchronize into this directory. +
  3. Create a subdirectory called shared (or current, or +whatever) in your home directory on each host, and put links to +all the files you want to synchronize into this directory. Use the +follow preference (see the Symbolic Links section) to make +Unison treat these links as transparent. +
  4. 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 -path switch +on the command line: +
    +       unison /home/username ssh://remotehost//home/username -path shared
+
    +The -path option can be used as many times as needed, to +synchronize several files or subdirectories: +
    +       unison /home/username ssh://remotehost//home/username \
+          -path shared \
+          -path pub \
+          -path .netscape/bookmarks.html
+
    +These -path arguments can also be put in your preference file. +See the Preferences section for an example. +
+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 rdist, where +the mirroring operation typically needs to be initiated from the +machine with the most recent changes. the Profile section +covers the syntax of Unison profiles, together with some sample profiles.
+
+Some tips on improving Unison's performance can be found on the +Frequently + Asked Questions page.
+
+ + +

Using Unison to Synchronize More Than Two Machines

+ +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.
+
+If you need to do this, the most reliable way to set things up is to +organize the machines into a “star topology,” with one machine designated +as the “hub” and the rest as “spokes,” 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 “spurious conflicts” +arising from the fact that a separate archive is maintained by Unison for +every pair of hosts that it synchronizes.
+
+ + +

Going Further

+ +On-line documentation for the various features of Unison +can be obtained either by typing +
+        unison -doc topics
+
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. +
+
+If you use Unison regularly, you should subscribe to one of the mailing +lists, to receive announcements of new versions. See +the Mailing Lists section.
+
+
+ +

Basic Concepts

+ +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 http://www.cis.upenn.edu/~bcpierce/papers. +But the informal presentation here should be enough for most users.
+
+ + +

Roots

+ +A replica's root tells Unison where to find a set of files to be +synchronized, either on the local machine or on a remote host. +For example, +
+      relative/path/of/root
+
+specifies a local root relative to the directory where Unison is +started, while +
+      /absolute/path/of/root
+
+specifies a root relative to the top of the local filesystem, +independent of where Unison is running. Remote roots can begin with +ssh://, +rsh:// +to indicate that the remote server should be started with rsh or ssh: +
+      ssh://remotehost//absolute/path/of/root
+      rsh://user@remotehost/relative/path/of/root
+
+If the remote server is already running (in the socket mode), then the syntax +
+      socket://remotehost:portnum//absolute/path/of/root
+      socket://remotehost:portnum/relative/path/of/root
+
+is used to specify the hostname and the port that the client Unison should +use to contact it.
+
+The syntax for roots is based on that of URIs (described in RFC 2396). +The full grammar is: +
+  replica ::= [protocol:]//[user@][host][:port][/path]
+           |  path
+
+  protocol ::= file
+            |  socket
+            |  ssh
+            |  rsh
+
+  user ::= [-_a-zA-Z0-9]+
+
+  host ::= [-_a-zA-Z0-9.]+
+
+  port ::= [0-9]+
+
+When path is given without any protocol prefix, the protocol is +assumed to be file:. Under Windows, it is possible to +synchronize with a remote directory using the file: protocol over +the Windows Network Neighborhood. For example, +
+       unison foo //host/drive/bar
+
synchronizes the local directory foo with the directory +drive:\bar on the machine host, provided that host +is accessible via Network Neighborhood. When the file: 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.
+
+The names of roots are canonized by Unison before it uses them +to compute the names of the corresponding archive files, so //saul//home/bcpierce/common and //saul.cis.upenn.edu/common +will be recognized as the same replica under different names.
+
+ + +

Paths

+ +A path refers to a point within a set of files being +synchronized; it is specified relative to the root of the replica.
+
+Formally, a path is just a sequence of names, separated by /. +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 c:\pierce with the root +ssh://saul.cis.upenn.edu/home/bcpierce on a Unix server. Then +the path current/todo.txt refers to the file +c:\pierce\current\todo.txt on the client and +/home/bcpierce/current/todo.txt on the server.)
+
+The empty path (i.e., the empty sequence of names) denotes the whole +replica. Unison displays the empty path as “[root].”
+
+If p is a path and q is a path beginning with p, then +q is said to be a descendant of p. (Each path is also a +descendant of itself.)
+
+ + +

What is an Update?

+ +The contents of a path p in a particular replica could be a +file, a directory, a symbolic link, or absent (if p does not +refer to anything at all in that replica). More specifically: + +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).
+
+We say that a path is updated (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—Unison considers only the contents when +determining whether an update has occurred. This means that touching a file +without changing its contents will not 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.
+
+What Unison actually calculates is a close approximation to this +definition; see the Caveats and Shortcomings section.
+
+ + +

What is a Conflict?

+ +A path is said to be conflicting if the following conditions all hold: +
  1. +it has been updated in one replica, +
  2. it or any of its descendants has been updated in the other + replica, +and +
  3. its contents in the two replicas are not identical. +
+ + +

Reconciliation

+ +Unison operates in several distinct stages: +
  1. +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. +
  2. It checks for “false conflicts” — 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. +
  3. 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. +
  4. 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. +
  5. It updates its archive files to reflect the new state of the +replicas. +
+ + +

Invariants

+ +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.
+
+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: + +The upshot is that it is safe to interrupt Unison at any time, either +manually or accidentally. [Caveat: the above is almost 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 DANGER.README 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.]
+
+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.
+
+If Unison is interrupted, it may sometimes leave temporary working files +(with suffix .tmp) in the replicas. It is safe to delete these +files. Also, if the backups flag is set, Unison will +leave around old versions of files that it overwrites, with names like +file.0.unison.bak. These can be deleted safely when they are no +longer wanted.
+
+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.
+
+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.
+
+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—the default on Unix systems—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 +-times option allows you to synchronize file times, but it does not +cause identical files to be changed; Unison will only modify the file +times.)
+
+It is safe to “brainwash” Unison by deleting its archive files +on both replicas. The next time it runs, it will assume that +all the files it sees in the replicas are new.
+
+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. +
+
+Changes to the ignore patterns from the user interface (e.g., using +the `i' key) are immediately reflected in the current profile.
+
+ + +

Caveats and Shortcomings

+ +Here are some things to be careful of when using Unison. + +
+ +

Reference Guide

+ +This section covers the features of Unison in detail.
+
+ + +

Running Unison

+ +There are several ways to start Unison. + + + +

The .unison Directory

+ +Unison stores a variety of information in a private directory on each +host. If the environment variable UNISON is defined, then its +value will be used as the name of this directory. If UNISON is +not defined, then the name of the directory depends on which +operating system you are using. In Unix, the default is to use +$HOME/.unison. +In Windows, if the environment variable +USERPROFILE is defined, then the directory will be +$USERPROFILE\.unison; +otherwise if HOME is defined, it will be +$HOME\.unison; +otherwise, it will be +c:\.unison.
+
+The archive file for each replica is found in the .unison +directory on that replica's host. Profiles (described below) are +always taken from the .unison directory on the client host.
+
+Note that Unison maintains a completely different set of archive files +for each pair of roots.
+
+We do not recommend synchronizing the whole .unison 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 .unison directory is definitely OK.
+
+ + +

Archive Files

+ +The name of the archive file on each replica is calculated from + +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.
+
+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 +gethostname operating system call. However, if the environment +variable UNISONLOCALHOSTNAME 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).
+
+A more powerful way of changing archive names is provided by the +rootalias preference. The preference file may contain any number of +lines of the form: +
+    rootalias = //hostnameA//path-to-replicaA -> //hostnameB//path-to-replicaB
+
+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.
+
+So, if you need to relocate a root on one of the hosts, you can add a +rule of the form: +
+    rootalias = //new-hostname//new-path -> //old-hostname//old-path
+
+Warning: The rootalias 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 rootalias, it is a good idea to run Unison +a few times interactively (with the batch flag off, etc.) and +carefully check that things look reasonable—in particular, that update +detection is working as expected.
+
+ + +

Preferences

+ +Many details of Unison's behavior are configurable by user-settable +“preferences.”
+
+Some preferences are boolean-valued; these are often called flags. +Others take numeric or string arguments, indicated in the preferences +list by n or xxx. Most of the string preferences can be +given several times; the arguments are accumulated into a list +internally.
+
+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 profile in the .unison +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.
+
+To set the value of a preference p from the command line, add an +argument -p (for a boolean flag) or -p n or -p xxx (for +a numeric or string preference) anywhere on the command line. To set a +boolean flag to false on the command line, use -p=false.
+
+Here are all the preferences supported by Unison. This list can be + obtained by typing unison -help. +
+
+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' -> everything, 'verbose' -> 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
+
+
+Here, in more detail, are what they do. Many are discussed in even greater +detail in other sections of the manual. +
+addprefsto xxx
+By default, new preferences added by Unison (e.g., new ignore clauses) will be appended to whatever preference file Unison was told to load at the beginning of the run. Setting the preference addprefsto filename makes Unison add new preferences to the file named filename instead.
+
+
addversionno
+When this flag is set to true, Unison will use unison-currentversionnumber instead of just unison 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.
+
+
auto
+When set to true, 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.)
+
+
backup xxx
+Including the preference -backup pathspec causes Unison to keep backup files for each path that matches pathspec. These backup files are kept in the directory specified by the backuplocation preference. The backups are named according to the backupprefix and backupsuffix preferences. The number of versions that are kept is determined by the maxbackups preference.
+
+The syntax of pathspec is described in the Path Specification section.
+
+
backupcurrent xxx
+Including the preference -backupcurrent pathspec causes Unison to keep a backup of the current version of every file matching pathspec. 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 merge preference. For more details, see the Merging Conflicting Versions section.
+
+The syntax of pathspec is described in the Path Specification section.
+
+
backupcurrentnot xxx
+Exceptions to backupcurrent, like the ignorenot preference.
+
+
backupdir xxx
+If this preference is set, Unison will use it as the name of the directory used to store backup files specified by the backup preference, when backuplocation is set to central. It is checked after the UNISONBACKUPDIR environment variable.
+
+
backuplocation xxx
+This preference determines whether backups should be kept locally, near the original files, or in a central directory specified by the backupdir preference. If set to local, backups will be kept in the same directory as the original files, and if set to central, backupdir will be used instead.
+
+
backupnot xxx
+The values of this preference specify paths or individual files or regular expressions that should not be backed up, even if the backup preference selects them—i.e., it selectively overrides backup. The same caveats apply here as with ignore and t ignorenot.
+
+
backupprefix xxx
+When a backup for a file NAME is created, it is stored in a directory specified by backuplocation, in a file called backupprefixNAMEbackupsuffix. backupprefix can include a directory name (causing Unison to keep all backup files for a given directory in a subdirectory with this name), and both backupprefix and backupsuffix can contain the string$VERSION, which will be replaced by the age 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.
+
+
backups
+Setting this flag to true is equivalent to setting backuplocation to local and backup to Name *.
+
+
backupsuffix xxx
+See backupprefix for full documentation.
+
+
batch
+When this is set to true, the user interface will ask no questions at all. Non-conflicting changes will be propagated; conflicts will be skipped.
+
+
confirmmerge
+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.
+
+
contactquietly
+If this flag is set, Unison will skip displaying the `Contacting server' window (which some users find annoying) during startup.
+
+
debug xxx
+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 debug can be found by looking for calls to Util.debug in the sources (using, e.g., grep). Setting -debug all causes information from all 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); -debug verbose turns on some additional debugging output from some modules (e.g., it will show exactly what bytes are being sent across the network).
+
+
diff xxx
+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 `diff -u'. 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.
+
+
doc xxx
+The command-line argument -doc secname causes unison to display section secname of the manual on the standard output and then exit. Use -doc all to display the whole manual, which includes exactly the same information as the printed and HTML manuals, modulo formatting. Use -doc topics to obtain a list of the names of the various sections that can be printed.
+
+
dumbtty
+When set to true, 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.
+
+When dumbtty 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.)
+
+This preference has no effect on the graphical user interface.
+
+
dumparchives
+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.
+
+
fastcheck xxx
+When this preference is set to true, 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 overwrite 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 fastcheck set to false, if you are worried that Unison may have overlooked an update. The default value of the preference is auto, which causes Unison to use fast checking on Unix replicas (where it is safe) and slow checking on Windows replicas. For backward compatibility, yes, no, and default can be used in place of true, false, and auto. See the Fast Checking section for more information.
+
+
follow xxx
+Including the preference -follow pathspec causes Unison to treat symbolic links matching pathspec as `invisible' and behave as if the object pointed to by the link had appeared literally at this position in the replica. See the Symbolic Links section for more details. The syntax of pathspec> is described in the Path Specification section.
+
+
force xxx
+Including the preference -force root causes Unison to resolve all differences (even non-conflicting changes) in favor of root. This effectively changes Unison from a synchronizer into a mirroring utility.
+
+You can also specify -force newer (or -force older) to force Unison to choose the file with the later (earlier) modtime. In this case, the -times preference must also be enabled.
+
+This preference should be used only if you are sure you know what you are doing!
+
+
group
+When this flag is set to true, the group attributes of the files are synchronized. Whether the group names or the group identifiers are synchronizeddepends on the preference numerids.
+
+
height n
+Used to set the height (in lines) of the main window in the graphical user interface.
+
+
ignore xxx
+Including the preference -ignore pathspec causes Unison to completely ignore paths that match pathspec (as well as their children). This is useful for avoiding synchronizing temporary files, object files, etc. The syntax of pathspec is described in the Path Specification section, and further details on ignoring paths is found in the Ignoring Paths section.
+
+
ignorecase xxx
+When set to true, this flag causes Unison to treat filenames as case insensitive—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 false, 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).
+
+
ignorelocks
+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 positive 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.
+
+
ignorenot xxx
+This preference overrides the preference ignore. + It gives a list of patterns + (in the same format as + ignore) for paths that should definitely not be ignored, + whether or not they happen to match one of the ignore patterns. +
+
+Note that the semantics of ignore and ignorenot 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 ignore and does not match ignorenot; in this case + it skips this path and all its descendants. This means that, + if some parent of a given path matches an ignore pattern, then + it will be skipped even if the path itself matches an ignorenot + pattern. In particular, putting ignore = Path * in your profile + and then using t ignorenot to select particular paths to be + synchronized will not work. Instead, you should use the path + preference to choose particular paths to synchronize.
+
+
immutable xxx
+This preference specifies paths for directories whose children are all immutable files — 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).
+
+
immutablenot xxx
+This preference overrides immutable.
+
+
key xxx
+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.
+
+
killserver
+When set to true, this flag causes Unison to kill the remote server process when the synchronization is finished. This behavior is the default for ssh connections, so this preference is not normally needed when running over ssh; 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.)
+
+
label xxx
+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.)
+
+
log
+When this flag is set, Unison will log all changes to the filesystems + on a file.
+
+
logfile xxx
+By default, logging messages will be appended to the file + unison.log in your HOME directory. Set this preference if + you prefer another file.
+
+
maxbackups n
+This preference specifies the number of backup versions that will be kept by unison, for each path that matches the predicate backup. The default is 2.
+
+
maxthreads n
+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.
+
+
merge xxx
+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 merge preference for a path will also cause this path to be backed up, just like t backup. The syntax of pathspec>cmd is described in the Path Specification section, and further details on Merging functions are present in the Merging files section.
+
+
mergebatch xxx
+Normally, when Unison is run with the batch 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 mergebatch preference instead of merge. When running in non-batch mode, the merge preference is used instead of mergebatch if both are specified for a given path.
+
+
numericids
+When this flag is set to true, groups and users are synchronized numerically, rather than by name.
+
+The special uid 0 and the special group 0 are never mapped via user/group names even if this preference is not set.
+
+
owner
+When this flag is set to true, the owner attributes of the files are synchronized. Whether the owner names or the owner identifiers are synchronizeddepends on the preference extttnumerids.
+
+
path xxx
+When no path preference is given, Unison will simply synchronize the two entire replicas, beginning from the given pair of roots. If one or more path 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 path preferences are intepreted literally—they are not regular expressions.
+
+
perms n
+The integer value of this preference is a mask indicating which permission bits should be synchronized. It is set by default to 0o1777: 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 −1.
+
+
prefer xxx
+Including the preference -prefer root causes Unison always to resolve conflicts in favor of root, rather than asking for guidance from the user. (The syntax of root is the same as for the root preference, plus the special values newer and older.)
+
+This preference should be used only if you are sure you know what you are doing!
+
+
pretendwin
+When set to true, this preference makes Unison use Windows-style fast update detection (using file creation times as “pseudo-inode-numbers”), 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 fastcheck option should also be set to true.
+
+
repeat xxx
+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—called a changelog—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.
+
+
retry n
+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.
+
+
root xxx
+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 root 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 Roots section.
+
+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.
+
+
rootalias xxx
+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.
+
+
rshargs xxx
+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 rsh command used to invoke the remote server.
+
+
rshcmd xxx
+This preference can be used to explicitly set the name of the rsh executable (e.g., giving a full path name), if necessary.
+
+
rsrc xxx
+When set to true, 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 false, Unison will not synchronize these data. Ordinarily, the flag is set to default, and these data are + automatically synchronized if either host is running OSX. In rare circumstances it is useful to set the flag manually.
+
+
rsync
+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.
+
+
servercmd xxx
+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.
+
+
showarchive
+When this preference is set, Unison will print out the 'true names'of the roots, in the same form as is expected by the rootaliaspreference.
+
+
silent
+When this preference is set to true, the textual user interface will print nothing at all, except in the case of errors. Setting silent to true automatically sets the batch preference to true.
+
+
sortbysize
+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.
+
+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.
+
+
sortfirst xxx
+Each argument to sortfirst is a pattern pathspec, which describes a set of paths. Files matching any of these patterns will be listed first in the user interface. The syntax of pathspec is described in the Path Specification section.
+
+
sortlast xxx
+Similar to sortfirst, except that files matching one of these patterns will be listed at the very end.
+
+
sortnewfirst
+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.
+
+
sshargs xxx
+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 ssh command used to invoke the remote server.
+
+
sshcmd xxx
+This preference can be used to explicitly set the name of the ssh executable (e.g., giving a full path name), if necessary.
+
+
sshversion xxx
+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 ssh1 orssh2 instead of just ssh to invoke ssh. The default value is empty, which will make unison use whatever version of ssh is installed as the default `ssh' command.
+
+
terse
+When this preference is set to true, the user interface will not print status messages.
+
+
testserver
+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.
+
+
times
+When this flag is set to true, file modification times (but not directory modtimes) are propagated.
+
+
ui xxx
+This preference selects either the graphical or the textual user interface. Legal values are graphic or text.
+
+Because this option is processed specially during Unison's start-up sequence, it can only be used on the command line. In preference files it has no effect.
+
+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.)
+
+
version
+Print the current version number and exit. (This option only makes sense on the command line.)
+
+
xferbycopying
+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 istrue.
+ + + + +

Profiles

+ +A profile 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 .unison directory on the client +machine. If Unison is started with just one argument name on +the command line, it looks for a profile called name.prf in +the .unison directory. If it is started with no arguments, it +scans the .unison directory for files whose names end in +.prf and offers a menu (provided that the Unison executable is compiled with the graphical user interface). If a file named default.prf is +found, its settings will be offered as the default choices.
+
+To set the value of a preference p permanently, add to the +appropriate profile a line of the form +
+        p = true
+
for a boolean flag or +
+        p = <value>
+
for a preference of any other type.
+
+Whitespaces around p and xxx are ignored. +A profile may also include blank lines and lines beginning +with #; both are ignored.
+
+When Unison starts, it first reads the profile and then the command +line, so command-line options will override settings from the +profile.
+
+Profiles may also include lines of the form include + name, which will cause the file name (or +name.prf, if name does not exist in the +.unison directory) to be read at the point, and included as if +its contents, instead of the include line, was part of the +profile. Include lines allows settings common to several profiles to +be stored in one place.
+
+A profile may include a preference `label = desc' to +provide a description of the options selected in this profile. The +string desc 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.
+
+The graphical user-interface also supports one-key shortcuts for commonly +used profiles. If a profile contains a preference of the form +`key = n', where n 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.
+
+ + +

Sample Profiles

+ + + +

A Minimal Profile

+ +Here is a very minimal profile file, such as might be found in .unison/default.prf: +
+    # Roots of the synchronization
+    root = /home/bcpierce
+    root = ssh://saul//home/bcpierce
+
+    # Paths to synchronize 
+    path = current
+    path = common
+    path = .netscape/bookmarks.html
+
+ + +

A Basic Profile

+ +Here is a more sophisticated profile, illustrating some other useful +features. +
+    # 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
+
+ + +

A Power-User Profile

+ +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 — a common +part containing most of the preference settings, plus one “top-level” +file for each set of paths that need to be synchronized. (The include mechanism can also be used to allow the same set of preference +settings to be used with different roots.)
+
+The collection +of profiles implementing this scheme might look as follows. +The file default.prf is empty except for an include +directive: +
+    # Include the contents of the file common
+    include common
+
Note that the name of the common file is common, not common.prf; this prevents Unison from offering common as one of +the list of profiles in the opening dialog (in the graphical UI).
+
+The file common contains the real preferences: +
+    # 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
+
Note that there are no path preferences in common. This +means that, when we invoke Unison with the default profile (e.g., by +typing 'unison default' or just 'unison' on the command +line), the whole replicas will be synchronized. (If we never want +to synchronize the whole replicas, then default.prf would instead +include settings for all the paths that are usually synchronized.)
+
+To synchronize just part of the replicas, Unison is invoked with an +alternate preference file—e.g., doing 'unison workingset', where the +preference file workingset.prf contains +
+    path = current/papers
+    path = Mail/inbox
+    path = Mail/drafts
+    include common
+
causes Unison to synchronize just the subdirectories current/papers +and older/papers.
+
+The key preference can be used in combination with the graphical UI +to quickly switch between different sets of paths. For example, if the +file mail.prf contains +
+    path = Mail
+    batch = true
+    key = 2
+    include common
+
then pressing 2 will cause Unison to look for updates in the Mail +subdirectory and (because the batch flag is set) immediately +propagate any that it finds.
+
+ + +

Keeping Backups

+ +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.
+
+To enable backups, you must give one or more backup preferences. +Each of these has the form +
+    backup = <pathspec>
+
where <pathspec> has the same form as for the ignore +preference. For example, +
+    backup = Name *
+
causes Unison to keep backups of all files and directories. The +backupnot preference can be used to give a few exceptions: it +specifies which files and directories should not be backed up, even if +they match the backup pathspec.
+
+It is important to note that the pathspec is matched against the path +that is being updated by Unison, not its descendants. For example, if you +set backup = Name *.txt and then delete a whole directory named +foo containing some text files, these files will not be backed up +because Unison will just check that foo does not match *.txt. +Similarly, if the directory itself happened to be called foo.txt, +then the whole directory and all the files in it will be backed up, +regardless of their names.
+
+Backup files can be stored either centrally or locally. This +behavior is controlled by the preference backuplocation, whose value +must be either central or local. (The default is +central.)
+
+When backups are stored locally, they are kept in the same +directory as the original.
+
+When backups are stored centrally, the directory used to hold them is +controlled by the preference backupdir and the +environment variable UNISONBACKUPDIR. (The environment variable is +checked first.) If neither of these are set, then the directory +.unison/backup in the user's home directory is used.
+
+The preference backupversions controls how many previous versions of +each file are kept. The default is 2.
+
+By default, backup files are named .unison.FILENAME.VERSION.bak, +where FILENAME is the original filename and version is the +backup number (001 for the most recent, 002 for the next most recent, +etc.). This can be changed by setting the preferences backupprefix +and/or backupsuffix. If desired, backupprefix may include a +directory prefix; this can be used with backuplocation = local to put all +backup files for each directory into a single subdirectory. For example, setting +
+    backuplocation = local
+    backupprefix = .unison/$VERSION.
+    backupsuffix = 
+
will put all backups in a local subdirectory named .unison. Also, +note that the string $VERSION in either backupprefix or +backupsuffix (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.
+
+For backward compatibility, the backups preference is also supported. +It simply means backup = Name * and backuplocation = local.
+
+ + +

Merging Conflicting Versions

+ +Unison can invoke external programs to merge conflicting versions of a file. +The preference merge controls this process.
+
+The merge 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: +
+    merge = <PATHSPEC> -> <MERGECMD>
+
The <PATHSPEC> here has exactly the same format as for the +ignore preference (see the Path specification section). For example, +using “Name *.txt” as the <PATHSPEC> tells Unison that this +command should be used whenever a file with extension .txt needs to +be merged.
+
+Many external merging programs require as inputs not just the two files that +need to be merged, but also a file containing the last synchronized + version. You can ask Unison to keep a copy of the last synchronized +version for some files using the backupcurrent preference. This +preference is used in exactly the same way as backup and its meaning +is similar, except that it causes backups to be kept of the current +contents of each file after it has been synchronized by Unison, rather than +the previous contents that Unison overwrote. These backups are kept +on both replicas in the same place as ordinary backup files—i.e. +according to the backuplocation and backupdir preferences. +They are named like the original files if backupslocation is set to +'central' and otherwise, Unison uses the backupprefix and +backupsuffix preferences and assumes a version number 000 for these +backups.
+
+The <MERGECMD> part of the preference specifies what external command +should be invoked to merge files at paths matching the <PATHSPEC>. +Within this string, several special substrings are recognized; these will be +substituted with appropriate values before invoking a sub-shell to execute +the command. + +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: + +If the confirmmerge 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.
+
+A large number of external merging programs are available. +For example, on Unix systems setting the merge preference to +
+    merge = Name *.txt -> diff3 CURRENT1 CURRENTARCH CURRENT2 -m > NEW
+
will tell Unison to use the external diff3 program for merging. +Alternatively, users of emacs may find the following settings convenient: +
+    merge = Name *.txt -> emacs -q --eval '(ediff-merge-files-with-ancestor 
+                             "CURRENT1" "CURRENT2" "CURRENTARCH" nil "NEW")' 
+
(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 opendiff utility) may prefer +
+    merge = Name *.txt -> opendiff CURRENT1 CURRENT2 -ancestor CURRENTARCH -merge NEW
+
Here is a slightly more involved hack. The opendiff program can +operate either with or without an archive file. A merge command of this +form +
+    merge = Name *.txt -> 
+              if [ CURRENTARCHOPTx = x ]; 
+              then opendiff CURRENT1 CURRENT2 -merge NEW; 
+              else opendiff CURRENT1 CURRENT2 -ancestor CURRENTARCHOPT -merge NEW; 
+              fi
+
(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 opendiff.
+
+Ordinarily, external merge programs are only invoked when Unison is not running in batch mode. To specify an external merge program that +should be used no matter the setting of the batch flag, use the mergebatch preference instead of merge. +
+Please post suggestions for other useful values of the +merge preference to the unison-users mailing list—we'd like +to give several examples here. +
+ + +

The User Interface

+ +Both the textual and the graphical user interfaces are intended to be +mostly self-explanatory. Here are just a few tricks: + + + +

Exit code

+ +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: + +The graphical interface does not return any useful information through the +exit status.
+
+ + +

Path specification

+ +Several Unison preferences (e.g., ignore/ignorenot, +follow, sortfirst/sortlast, backup, +merge, 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. + +Some examples of path patterns appear in the Ignoring + Paths section.
+
+ + +

Ignoring Paths

+ +Most users of Unison will find that their replicas contain lots of +files that they don't ever want to synchronize — temporary files, +very large files, old stuff, architecture-specific binaries, etc. +They can instruct Unison to ignore these paths using patterns +introduced in the Path Patterns section.
+
+For example, the following pattern will make Unison ignore any +path containing the name CVS or a name ending in .cmo: +
+             ignore = Name {CVS,*.cmo}
+
The next pattern makes Unison ignore the path a/b: +
+             ignore = Path a/b
+
Path patterns do not skip filesnames beginning with . (as Name +patterns do). For example, +
+             ignore = Path */tmp
+
will include .foo/tmp in the set of ignore directories, as it is a +path, not a name, that is ignored.
+
+The following pattern makes Unison ignore any path beginning with a/b +and ending with a name ending by .ml. +
+             ignore = Regex a/b/.*\.ml
+
Note that regular expression patterns are “anchored”: they must +match the whole path, not just a substring of the path.
+
+Here are a few extra points regarding the ignore preference. + + + +

Symbolic Links

+ +Ordinarily, Unison treats symbolic links in Unix replicas as +“opaque”: 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.
+
+It is sometimes useful to treat a symbolic link “transparently,” +acting as though whatever it points to were physically in 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 +
+             follow = pathspec
+
+to the profile, where pathspec is a path pattern as described in +the Path Patterns section.
+
+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 +ignore pattern or a follow pattern.
+
+ + +

Permissions

+ +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: + + + + + +

Cross-Platform Synchronization

+ +If you use Unison to synchronize files between Windows and Unix +systems, there are a few special issues to be aware of.
+
+Case conflicts. In Unix, filenames are case sensitive: +foo and FOO can refer to different files. In +Windows, on the other hand, filenames are not case sensitive: +foo and FOO can only refer to the same file. This +means that a Unix foo and FOO cannot be synchronized +onto a Windows system — Windows won't allow two different files to +have the “same” name. Unison detects this situation for you, and +reports that it cannot synchronize the files.
+
+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 Ignore section).
+
+Illegal filenames. 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 foo:bar 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.
+
+ + +

Slow Links

+ +Unison is built to run well even over relatively slow links such as +modems and DSL connections.
+
+Unison uses the “rsync protocol” 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 (http://samba.anu.edu.au/rsync/).
+
+If you are using Unison with ssh, you may get some speed +improvement by enabling ssh's compression feature. Do this by +adding the option “-rshargs -C” to the command line or “rshargs = -C” to your profile.
+
+ + +

Fast Update Detection

+ +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—the only completely safe way to do it under Windows) is too slow. +Unison provides a preference fastcheck that, when set to +yes, 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.
+
+When fastcheck is set to no, +Unison will perform slow checking—re-scanning the contents of each file +on each synchronization—on all replicas. When fastcheck is set +to default (which, naturally, is the default), Unison will use +fast checks on Unix replicas and slow checks on Windows replicas.
+
+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 overwrite 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 fastcheck set to no, if you are worried that Unison may have +overlooked an update.
+
+ + +

Click-starting Unison

+ +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, as long as you are not using ssh. +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.
+
+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.
+
+To use Unison in this mode, you must first create a profile (see +the Profile section). Use your favorite editor for this.
+
+
+ +

Installing Ssh

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

Unix

+ +Most modern Unix installations come with ssh pre-installed.
+
+ + +

Windows

+ +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. (Warning: These instructions may be out of date.) +
  1. +Download an ssh executable.
    +
    +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: +
    1. +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 Foo. +
    2. Direct your web browser to www.cygwin.com, and click on the + “Install now!” link. This will download a file, setup.exe; + save it in the directory Foo. The file setup.exe is a + small program that will download the actual install files from + the Internet when you run it. +
    3. Start setup.exe (by double-clicking). This brings up a + series of dialogs that you will have to go through. Select + “Install from Internet.” For “Local Package Directory” select + the directory Foo. For “Select install root directory” we + recommend that you use the default, C:\cygwin. 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 “Use IE5 + Settings” 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.
      +
      +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 “skip” is shown. For a + minimum installation, select only the packages “cygwin” and + “openssh,” which come to about 1900KB; the full installation is + much larger. +
      Note that you are plan to build unison using the free + CygWin GNU C compiler, you need to install essential development + packages such as “gcc”, “make”, “fileutil”, etc; we refer to + the file “INSTALL.win32-cygwin-gnuc” in the source distribution + for further details. +
      +After the packages are downloaded and installed, the next dialog + allows you to choose whether to “Create Desktop Icon” and “Add to + Start Menu.” You make the call. +
    4. You can now delete the directory Foo and its contents. +
    +Some people have reported problems using Cygwin's ssh with Unison. If +you have trouble, you might try this one instead: +
    +  http://opensores.thebunker.net/pub/mirrors/ssh/contrib/ssh-1.2.14-win32bin.zip
+

    +
    +
  2. You must set the environment variables HOME and PATH. + Ssh will create a directory .ssh 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 bin + directory, so that Unison can find the ssh executable. +
    • + On Windows 95/98, add the lines +
      +    set PATH=%PATH%;<SSHDIR>
+    set HOME=<HOMEDIR>
+
      to the file C:\AUTOEXEC.BAT, where <HOMEDIR> is the + directory where you want ssh to create its .ssh directory, + and <SSHDIR> is the directory where the executable + ssh.exe is stored; if you've installed Cygwin in the + default location, this is C:\cygwin\bin. You will have to + reboot your computer to take the changes into account. +
    • On Windows NT/2k/XP, open the environment variables dialog box: +
      • + Windows NT: My Computer/Properties/Environment +
      • Windows 2k: My Computer/Properties/Advanced/Environment + variables +
      + then select Path and edit its value by appending ;<SSHDIR> + to it, where <SSHDIR> is the full name of the directory + that includes the ssh executable; if you've installed Cygwin in + the default location, this is C:\cygwin\bin. +
    +
  3. Test ssh from a DOS shell by typing +
    +      ssh <remote host> -l <login name>
+
    You should get a prompt for your password on <remote host>, + followed by a working connection. +
  4. Note that ssh-keygen may not work (fails with + “gethostname: no such file or directory”) on some systems. This is + OK: you can use ssh with your regular password for the remote + system. +
  5. 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., //username@host/path...). +
+
+ +

Changes in Version 2.17.1

+ +Changes since 2.13.0: + + +Changes since 2.12.0: + + +Changes since 2.10.2: + + +Changes since 2.9.20: + + +Changes since 2.9.1: + + +Changes since 2.8.1: + + +Changes since 2.7.78: + + +Changes since 2.7.39: + + +Changes since 2.7.7: + + +Changes since 2.7.4: + + +Changes since 2.7.1: + + +Changes since 2.6.59: + + +Changes since 2.6.38: + + +Changes since 2.6.11: + + +Changes since 2.6.1: + + +Changes since 2.5.31: + + +Changes since 2.5.25: + + +Changes since 2.5.1: + + +Changes since 2.4.1: + + +Changes since 2.3.12: + + +Changes since 2.3.1: + + +Changes since 2.2: + + +Changes since 2.1: + + +Changes since 1.292: + + +Changes since 1.231: + + +Changes since 1.219: + + +Changes since 1.200: + + +Changes since 1.190: + + +Changes since 1.180: + + +Changes since 1.169: + + +Changes since 1.146: + + +Changes since 1.142: + + +Changes since 1.139: + + +Changes since 1.111: + + +

+
+ + + +
This document was translated from LATEX by +HEVEA.
+ diff --git a/unison-2.17.1.tar.gz b/unison-2.17.1.tar.gz new file mode 100644 index 0000000..c654b9f --- /dev/null +++ b/unison-2.17.1.tar.gz @@ -0,0 +1,3 @@ +version https://git-lfs.github.com/spec/v1 +oid sha256:7a1173921237dd3e0ca758f4ba902a3d54eb04385a4450459f349a8846b7052c +size 415057 diff --git a/unison-windowout.diff b/unison-windowout.diff new file mode 100644 index 0000000..9699534 --- /dev/null +++ b/unison-windowout.diff @@ -0,0 +1,57 @@ +Index: uigtk2.ml +=================================================================== +--- uigtk2.ml (revision 184) ++++ uigtk2.ml (revision 185) +@@ -1118,10 +1118,9 @@ + + (* ------ *) + +-let messageBox ~title ~parent ?(action = fun t -> t#destroy) +- ?(modal = false) message = ++let messageBox ~title ?(action = fun t -> t#destroy) ?(modal = false) message = + let utitle = transcode title in +- let t = GWindow.dialog ~title:utitle ~parent ~modal ~position:`CENTER () in ++ let t = GWindow.dialog ~title:utitle ~modal ~position:`CENTER () in + let t_dismiss = GButton.button ~stock:`CLOSE ~packing:t#action_area#add () in + t_dismiss#grab_default (); + ignore (t_dismiss#connect#clicked ~callback:(action t)); +@@ -1156,7 +1155,7 @@ + ~selectable:true ~yalign:0. ~packing:v1#add ()); + t#add_button_stock `CANCEL `NO; + let cmd () = +- messageBox ~title:"Details" ~parent:t ~modal:false longtext ++ messageBox ~title:"Details" ~modal:false longtext + in + t#add_button advLabel `HELP; + t#add_button_stock `APPLY `YES; +@@ -1381,10 +1380,11 @@ + GBin.frame ~packing:(toplevelVBox#pack ~expand:false) + ~shadow_type:`IN (*~hpolicy:`AUTOMATIC ~vpolicy:`NEVER*) () in + let hb =GPack.hbox ~packing:sw#add () in +- (GButton.button ~label:"View details..." ~packing:hb#add (), ++ (GButton.button ~label:"View details..." ~packing:(hb#pack ~expand:false) (), + GText.view ~editable:false ~wrap_mode:`NONE ~packing:hb#add ()) + + in ++ showDetailsButton#misc#set_sensitive false; + detailsWindow#misc#modify_font (Lazy.force fontMonospaceMediumPango); + detailsWindow#misc#set_size_chars ~height:3 ~width:104 (); + detailsWindow#misc#set_can_focus false; +@@ -1396,7 +1396,7 @@ + (match !theState.(row).whatHappened with + Some (Util.Failed _, Some det) -> det + | _ -> "[No details available]") in +- messageBox ~title:"Merge execution details" ~parent:(getMyWindow ()) details ++ messageBox ~title:"Merge execution details" details + in + ignore (showDetailsButton#connect#clicked ~callback:showDetCommand); + +@@ -2075,7 +2075,7 @@ + Some i -> + getLock (fun () -> + Uicommon.showDiffs !theState.(i).ri +- (fun title text -> messageBox ~title ~parent:(getMyWindow ()) (transcode text)) ++ (fun title text -> messageBox ~title (transcode text)) + Trace.status (Uutil.File.ofLine i); + displayGlobalProgress 0.) + | None -> diff --git a/unison.changes b/unison.changes new file mode 100644 index 0000000..8809253 --- /dev/null +++ b/unison.changes @@ -0,0 +1,105 @@ +------------------------------------------------------------------- +Wed Dec 13 16:01:52 CET 2006 - mhopf@suse.de + +- added patch for no longer closing main window if subwindows open +- removed unison-gtk1 again + +------------------------------------------------------------------- +Wed Dec 6 22:55:50 CET 2006 - seife@suse.de + +- add unison-gtk1, a binary compiled against lablgtk + +------------------------------------------------------------------- +Mon Sep 25 17:08:31 CEST 2006 - mhopf@suse.de + +- Update to version 2.17.1 +- Completely rewritten backup function (actually working now) +- Ip V6 support +- Several bug fixes + +------------------------------------------------------------------- +Thu Sep 21 02:11:42 CEST 2006 - seife@suse.de + +- switch to GTK2 / lablgtk2 + +------------------------------------------------------------------- +Wed Jan 25 21:42:26 CET 2006 - mls@suse.de + +- converted neededforbuild to BuildRequires + +------------------------------------------------------------------- +Mon Oct 10 16:05:21 CEST 2005 - rommel@suse.de + +- update to version 2.13.16 (includes all of our recent fixes) +- updated spec file, manual is available in html now + +------------------------------------------------------------------- +Tue Mar 15 15:22:02 CET 2005 - ro@suse.de + +- enable optimized compile on x86_64 + +------------------------------------------------------------------- +Wed Sep 15 01:18:01 CEST 2004 - ro@suse.de + +- fix build with ocaml-3.08 (from unison-hackers ml) + +------------------------------------------------------------------- +Sat Jan 10 21:42:14 CET 2004 - adrian@suse.de + +- build as user + +------------------------------------------------------------------- +Fri Aug 15 17:00:41 CEST 2003 - adrian@suse.de + +- add desktop file + +------------------------------------------------------------------- +Tue Jul 22 11:59:27 CEST 2003 - rommel@suse.de + +- fixed "invalid escape sequence" error messages +- fixed %install (not using make install anymore) +- compiling with thread support + +------------------------------------------------------------------- +Wed May 7 01:35:49 CEST 2003 - ro@suse.de + +- fix tail calling syntax + +------------------------------------------------------------------- +Mon Jan 27 12:27:41 CET 2003 - rommel@suse.de + +- replaced pdf file (unreadable) with ps file + +------------------------------------------------------------------- +Tue Sep 17 17:34:28 CEST 2002 - ro@suse.de + +- removed bogus self-provides + +------------------------------------------------------------------- +Tue May 28 00:46:29 CEST 2002 - ro@suse.de + +- update to 2.9.1 makes it build with current ocaml + +------------------------------------------------------------------- +Fri Sep 14 12:48:12 CEST 2001 - grimmer@suse.de + +- Update to 2.7.7, which fixes the following bugs (since + 2.7.1): + + * Fixed a silly bug that would reliably prevent the Unison + client from starting in 2.7.4. + * Bug fix (2.7.4): read the initial connection header one byte + at a time, so that we don't block if the header is shorter + than expected. + +------------------------------------------------------------------- +Wed Aug 29 21:07:36 CEST 2001 - grimmer@suse.de + +- Update to 2.7.1 (see the NEWS file for changes) +- updated PDF manual to latest version + +------------------------------------------------------------------- +Thu Aug 16 17:26:58 CEST 2001 - grimmer@suse.de + +- Initial package for SuSE Linux (version 2.6.59) + diff --git a/unison.desktop b/unison.desktop new file mode 100644 index 0000000..189620e --- /dev/null +++ b/unison.desktop @@ -0,0 +1,5 @@ +[Desktop Entry] +Type=Application +Exec=unison +Name=unison + diff --git a/unison.spec b/unison.spec new file mode 100644 index 0000000..5d01c9e --- /dev/null +++ b/unison.spec @@ -0,0 +1,122 @@ +# +# spec file for package unison (Version 2.17.1) +# +# Copyright (c) 2006 SUSE LINUX Products GmbH, Nuernberg, Germany. +# This file and all modifications and additions to the pristine +# package are under the same license as the package itself. +# +# Please submit bugfixes or comments via http://bugs.opensuse.org/ +# + +# norootforbuild + +Name: unison +BuildRequires: gtk2-devel lablgtk2 update-desktop-files +License: GNU General Public License (GPL) +Group: Productivity/Networking/Other +Autoreqprov: on +Version: 2.17.1 +Release: 23 +Source0: http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-%{version}.tar.gz +Source1: http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-%{version}-manual.html +Source2: %name.desktop +Patch0: unison-windowout.diff +URL: http://www.cis.upenn.edu/~bcpierce/unison +BuildRoot: %{_tmppath}/%{name}-%{version}-build +Summary: A file synchronization tool + +%description +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, then brought up to date by propagating the changes in each +replica to the other. + + + +Authors: +-------- + Benjamin Pierce + +%prep +%setup -q +%patch0 + +%build +%ifarch s390 s390x +make UISTYLE=gtk2 NATIVE=false THREADS=false +%else +make UISTYLE=gtk2 NATIVE=true THREADS=true +%endif + +%install +[ "$RPM_BUILD_ROOT" != "/" ] && [ -d $RPM_BUILD_ROOT ] && rm -rf $RPM_BUILD_ROOT; +mkdir -p $RPM_BUILD_ROOT%{_bindir} +install -m 755 %name $RPM_BUILD_ROOT%{_bindir} +install -m 644 %{SOURCE1} unison-manual.html +%suse_update_desktop_file -i %name Utility SyncUtility +%ifarch s390 s390x +# do not strip non-optimized builds +export NO_BRP_STRIP_DEBUG=true +%endif + +%clean +rm -rf $RPM_BUILD_ROOT; + +%files +%defattr(-, root, root) +%doc BUGS.txt CONTRIB COPYING NEWS README ROADMAP.txt TODO.txt unison-manual.html +/usr/share/applications/* +%{_bindir}/%{name} + +%changelog -n unison +* Wed Dec 13 2006 - mhopf@suse.de +- added patch for no longer closing main window if subwindows open +- removed unison-gtk1 again +* Wed Dec 06 2006 - seife@suse.de +- add unison-gtk1, a binary compiled against lablgtk +* Mon Sep 25 2006 - mhopf@suse.de +- Update to version 2.17.1 +- Completely rewritten backup function (actually working now) +- Ip V6 support +- Several bug fixes +* Thu Sep 21 2006 - seife@suse.de +- switch to GTK2 / lablgtk2 +* Wed Jan 25 2006 - mls@suse.de +- converted neededforbuild to BuildRequires +* Mon Oct 10 2005 - rommel@suse.de +- update to version 2.13.16 (includes all of our recent fixes) +- updated spec file, manual is available in html now +* Tue Mar 15 2005 - ro@suse.de +- enable optimized compile on x86_64 +* Wed Sep 15 2004 - ro@suse.de +- fix build with ocaml-3.08 (from unison-hackers ml) +* Sat Jan 10 2004 - adrian@suse.de +- build as user +* Fri Aug 15 2003 - adrian@suse.de +- add desktop file +* Tue Jul 22 2003 - rommel@suse.de +- fixed "invalid escape sequence" error messages +- fixed %%install (not using make install anymore) +- compiling with thread support +* Wed May 07 2003 - ro@suse.de +- fix tail calling syntax +* Mon Jan 27 2003 - rommel@suse.de +- replaced pdf file (unreadable) with ps file +* Tue Sep 17 2002 - ro@suse.de +- removed bogus self-provides +* Tue May 28 2002 - ro@suse.de +- update to 2.9.1 makes it build with current ocaml +* Fri Sep 14 2001 - grimmer@suse.de +- Update to 2.7.7, which fixes the following bugs (since + 2.7.1): + * Fixed a silly bug that would reliably prevent the Unison + client from starting in 2.7.4. + * Bug fix (2.7.4): read the initial connection header one byte + at a time, so that we don't block if the header is shorter + than expected. +* Wed Aug 29 2001 - grimmer@suse.de +- Update to 2.7.1 (see the NEWS file for changes) +- updated PDF manual to latest version +* Thu Aug 16 2001 - grimmer@suse.de +- Initial package for SuSE Linux (version 2.6.59)