318 lines
220 KiB
HTML
318 lines
220 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"><HTML><HEAD><META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><META name="GENERATOR" content="hevea 1.08"><STYLE type="text/css">.toc{list-style:none}.title{margin:auto;text-align:center}.center{text-align:center;margin-left:auto;margin-right:auto}.flushleft{text-align:left;margin-left:0ex;margin-right:auto}.flushright{text-align:right;margin-left:auto;margin-right:0ex}DIV TABLE{margin-left:inherit;margin-right:inherit}PRE{text-align:left;margin-left:0ex;margin-right:auto}BLOCKQUOTE{margin-left:4ex;margin-right:4ex;text-align:left}.part{margin:auto;text-align:center}</STYLE> <META name="Author" content="Benjamin C. Pierce"><link rel="stylesheet" href="http://www.cis.upenn.edu/~bcpierce/unison/unison.css"></HEAD><BODY><BR><BR><div id="manualbody"><BR><BR><div id="manualheader"><DIV CLASS="center"><FONT SIZE=7><FONT COLOR=black>Unison File Synchronizer</FONT><BR><FONT SIZE=6><FONT COLOR=black>User Manual and Reference Guide</FONT><BR><FONT SIZE=5>Version 2.27.57<BR></FONT></FONT></FONT></DIV></div><BR><BR><H2 CLASS="section">Contents</H2><BLOCKQUOTE CLASS="quote"><A HREF="#intro"><FONT SIZE=4><B>Preface</B></FONT></A><BR> •<A HREF="#people">People</A><BR> •<A HREF="#lists">Mailing Lists and Bug Reporting</A><BR> •<A HREF="#status">Development Status</A><BR> •<A HREF="#copying">Copying</A><BR> •<A HREF="#ack">Acknowledgements</A><BR><A HREF="#install"><FONT SIZE=4><B>Installation</B></FONT></A><BR> •<A HREF="#download">Downloading Unison</A><BR> •<A HREF="#afterinstall">Running Unison</A><BR> •<A HREF="#upgrading">Upgrading</A><BR> •<A HREF="#building">Building Unison from Scratch</A><BR> <A HREF="#build-unix">Unix</A><BR> <A HREF="#build-win">Windows</A><BR> <A HREF="#build-opts">Installation Options</A><BR><A HREF="#tutorial"><FONT SIZE=4><B>Tutorial</B></FONT></A><BR> •<A HREF="#prelim">Preliminaries</A><BR> •<A HREF="#local">Local Usage</A><BR> •<A HREF="#remote">Remote Usage</A><BR> •<A HREF="#rshmeth">Remote Shell Method</A><BR> •<A HREF="#socketmeth">Socket Method</A><BR> •<A HREF="#usingit">Using Unison for All Your Files</A><BR> •<A HREF="#usingmultiple">Using Unison to Synchronize More Than Two Machines</A><BR> •<A HREF="#further">Going Further</A><BR><A HREF="#basics"><FONT SIZE=4><B>Basic Concepts</B></FONT></A><BR> •<A HREF="#roots">Roots</A><BR> •<A HREF="#paths">Paths</A><BR> •<A HREF="#update
|
||
|
|
make NATIVE=false
|
||
|
|
</PRE>to compile the bytecode. The result should be an executable file called <CODE>unison.exe</CODE>.<BR><BR><H5 CLASS="paragraph">Native version:</H5>Building a more efficient, native version of Unison on Windows requires a little more work. See the file <TT>INSTALL.win32</TT> in the source code distribution.<BR><BR><H4 CLASS="subsubsection"><A NAME="build-opts"></A>Installation Options</H4>The <CODE>Makefile</CODE> in the distribution includes several switches that can be used to control how Unison is built. Here are the most useful ones:<UL CLASS="itemize"><LI CLASS="li-itemize">Building with <CODE>NATIVE=true</CODE> uses the native-code OCaml compiler, yielding an executable that will run quite a bit faster. We use this for building distribution versions. <LI CLASS="li-itemize">Building with <CODE>make DEBUGGING=true</CODE> generates debugging symbols. <LI CLASS="li-itemize">Building with <CODE>make STATIC=true</CODE> generates a (mostly) statically linked executable. We use this for building distribution versions, for portability.</UL><hr><H2 CLASS="section"><A NAME="tutorial"></A>Tutorial</H2><H3 CLASS="subsection"><A NAME="prelim"></A>Preliminaries</H3>Unison can be used with either of two user interfaces:<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">a straightforward textual interface and <LI CLASS="li-enumerate">a more sophisticated graphical interface</OL>The textual interface is more convenient for running from scripts and works on dumb terminals; the graphical interface is better for most interactive use. For this tutorial, you can use either. If you are running Unison from the command line, just typing <TT>unison</TT> will select either the text or the graphical interface, depending on which has been selected as default when the executable you are running was built. You can force the text interface even if graphical is the default by adding <TT>-ui text</TT>. The other command-line arguments to both versions are identical.<BR><BR>The graphical version can also be run directly by clicking on its icon, but this may require a little set-up (see the <A HREF="#click">Click-starting Unison</A> section). For this tutorial, we assume that you're starting it from the command line.<BR><BR>Unison can synchronize files and directories on a single machine, or between two machines on a network. (The same program runs on both machines; the only difference is which one is responsible for displaying the user interface.) If you're only interested in a single-machine setup, then let's call that machine the <EM>client</EM>. If you're synchronizing two machines, let's call them <EM>client</EM> and <EM>server</EM>.<BR><BR><H3 CLASS="subsection"><A NAME="local"></A>Local Usage</H3>Let's get the client machine set up first and see how to synchronize two directories on a single machine.<BR><BR>Follow the instructions in the <A HREF="#install">Installation</A> section to either download or build an executable version of Unison, and install it somewhere on your search path. (If you just want to use the textual user interface, download the appropriate textui binary. If you just want to the graphical interface—or if you will use both interfaces [the gtkui binary actually has both compiled in]—then download the gtkui binary.)<BR><BR>Create a small test directory <TT>a.tmp</TT> containing a couple of files and/or subdirectories, e.g.,<PRE CLASS="verbatim">
|
||
|
|
mkdir a.tmp
|
||
|
|
touch a.tmp/a a.tmp/b
|
||
|
|
mkdir a.tmp/d
|
||
|
|
touch a.tmp/d/f
|
||
|
|
</PRE>Copy this directory to b.tmp:<PRE CLASS="verbatim">
|
||
|
|
cp -r a.tmp b.tmp
|
||
|
|
</PRE>Now try synchronizing <TT>a.tmp</TT> and <TT>b.tmp</TT>. (Since they are identical, synchronizing them won't propagate any changes, but Unison will remember the current state of both directories so that it will be able to tell next time what has changed.) Type:<PRE CLASS="verbatim">
|
||
|
|
unison a.tmp b.tmp
|
||
|
|
</PRE><BR><EM>Textual Interface:</EM><UL CLASS="itemize"><LI CLASS="li-itemize">You should see a message notifying you that all the files are actually equal and then get returned to the command line.</UL><BR><EM>Graphical Interface:</EM><UL CLASS="itemize"><LI CLASS="li-itemize">You should get a big empty window with a message at the bottom notifying you that all files are identical. Choose the Exit item from the File menu to get back to the command line.</UL>Next, make some changes in a.tmp and/or b.tmp. For example:<PRE CLASS="verbatim">
|
||
|
|
rm a.tmp/a
|
||
|
|
echo "Hello" > 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
|
||
|
|
</PRE>Run Unison again:<PRE CLASS="verbatim">
|
||
|
|
unison a.tmp b.tmp
|
||
|
|
</PRE>This time, the user interface will display only the files that have changed. If a file has been modified in just one replica, then it will be displayed with an arrow indicating the direction that the change needs to be propagated. For example,<PRE CLASS="verbatim">
|
||
|
|
<--- new file c [f]
|
||
|
|
</PRE>indicates that the file <TT>c</TT> has been modified only in the second replica, and that the default action is therefore to propagate the new version to the first replica. To <B>f</B>ollw Unison's recommendation, press the “f” at the prompt.<BR><BR>If both replicas are modified and their contents are different, then the changes are in conflict: <TT><-?-></TT> is displayed to indicate that Unison needs guidance on which replica should override the other.<PRE CLASS="verbatim">
|
||
|
|
new file <-?-> new file d/h []
|
||
|
|
</PRE>By default, neither version will be propagated and both replicas will remain as they are.<BR><BR>If both replicas have been modified but their new contents are the same (as with the file <TT>b</TT>), then no propagation is necessary and nothing is shown. Unison simply notes that the file is up to date.<BR><BR>These display conventions are used by both versions of the user interface. The only difference lies in the way in which Unison's default actions are either accepted or overriden by the user.<BR><BR><BR><EM>Textual Interface:</EM><UL CLASS="itemize"><LI CLASS="li-itemize">The status of each modified file is displayed, in turn. When the copies of a file in the two replicas are not identical, the user interface will ask for instructions as to how to propagate the change. If some default action is indicated (by an arrow), you can simply press Return to go on to the next changed file. If you want to do something different with this file, press “<CODE><</CODE>” or “<CODE>></CODE>” to force the change to be propagated from right to left or from left to right, or else press “<CODE>/</CODE>” to skip this file and leave both replicas alone. When it reaches the end of the list of modified files, Unison will ask you one more time whether it should proceed with the updates that have been selected.<BR><BR>When Unison stops to wait for input from the user, pressing “<CODE>?</CODE>” will always give a list of possible responses and their meanings.</UL><BR><EM>Graphical Interface:</EM><UL CLASS="itemize"><LI CLASS="li-itemize">The main window shows all the files that have been modified in either <TT>a.tmp</TT> or <TT>b.tmp</TT>. To override a default action (or to select an action in the case when there is no default), first select the file, either by clicking on its name or by using the up- and down-arrow keys. Then press either the left-arrow or “<CODE><</CODE>” key (to cause the version in b.tmp to propagate to a.tmp) or the right-arrow or “<CODE>></CODE>” key (which makes the a.tmp version override b.tmp).<BR><BR>Every keyboard command can also be invoked from the menus at the top of the user interface. (Conversely, each menu item is annotated with its keyboard equivalent, if it has one.)<BR><BR>When you are satisfied with the directions for the propagation of changes as shown in the main window, click the “Go” button to set them in motion. A check sign will be displayed next to each filename when the file has been dealt with.</UL><H3 CLASS="subsection"><A NAME="remote"></A>Remote Usage</H3>Next, we'll get Unison set up to synchronize replicas on two different machines.<BR><BR>Follow the instructions in the Installation section to download or build an executable version of Unison on the server machine, and install it somewhere on your search path. (It doesn't matter whether you install the textual or graphical version, since the copy of Unison on the server doesn't need to display any user interface at all.)<BR><BR>It is important that the version of Unison installed on the server machine is the same as the version of Unison on the client machine. But some flexibility on the version of Unison at the client side can be achieved by using the <CODE>-addversionno</CODE> option; see the <A HREF="#prefs">Preferences</A> section.<BR><BR>Now there is a decision to be made. Unison provides two methods for communicating between the client and the server:<UL CLASS="itemize"><LI CLASS="li-itemize"><EM>Remote shell method</EM>: To use this method, you must have some way of invoking remote commands on the server from the client's command line, using a facility such as <CODE>ssh</CODE>. This method is more convenient (since there is no need to manually start a “unison server” process on the server) and also more secure (especially if you use <CODE>ssh</CODE>).<BR><BR><LI CLASS="li-itemize"><EM>Socket method</EM>: This method requires only that you can get TCP packets from the client to the server and back. A draconian firewall can
|
||
|
|
ssh <I>remotehostname</I> unison -version
|
||
|
|
</PRE>should print the same version information as running<PRE CLASS="verbatim">
|
||
|
|
unison -version
|
||
|
|
</PRE>locally on the client. If remote execution fails, then either something is wrong with your ssh setup (e.g., “permission denied”) or else the search path that's being used when executing commands on the server doesn't contain the <CODE>unison</CODE> executable (e.g., “command not found”).<BR><BR>Create a test directory <TT>a.tmp</TT> in your home directory on the client machine.<BR><BR>Test that the local unison client can start and connect to the remote server. Type<PRE>
|
||
|
|
unison -testServer a.tmp ssh://<I>remotehostname</I>/a.tmp
|
||
|
|
</PRE>Now cd to your home directory and type:<PRE CLASS="verbatim">
|
||
|
|
unison a.tmp ssh://remotehostname/a.tmp
|
||
|
|
</PRE>The result should be that the entire directory <TT>a.tmp</TT> is propagated from the client to your home directory on the server.<BR><BR>After finishing the first synchronization, change a few files and try synchronizing again. You should see similar results as in the local case.<BR><BR>If your user name on the server is not the same as on the client, you need to specify it on the command line:<PRE CLASS="verbatim">
|
||
|
|
unison a.tmp ssh://username@remotehostname/a.tmp
|
||
|
|
</PRE><I>Notes:</I><UL CLASS="itemize"><LI CLASS="li-itemize">If you want to put <CODE>a.tmp</CODE> some place other than your home directory on the remote host, you can give an absolute path for it by adding an extra slash between <CODE>remotehostname</CODE> and the beginning of the path:<PRE CLASS="verbatim">
|
||
|
|
unison a.tmp ssh://remotehostname//absolute/path/to/a.tmp
|
||
|
|
</PRE><BR><BR><LI CLASS="li-itemize">You can give an explicit path for the <CODE>unison</CODE> executable on the server by using the command-line option <FONT SIZE=4><TT>-servercmd /full/path/name/of/unison</TT></FONT> or adding <FONT SIZE=4><TT>servercmd=/full/path/name/of/unison</TT></FONT> to your profile (see the <A HREF="#profile">Profile</A> section). Similarly, you can specify a explicit path for the <CODE>ssh</CODE> program using the <FONT SIZE=4><TT>-sshcmd</TT></FONT> option. Extra arguments can be passed to <CODE>ssh</CODE> by setting the <CODE>-sshargs</CODE> preference.</UL><H3 CLASS="subsection"><A NAME="socketmeth"></A>Socket Method</H3><BLOCKQUOTE CLASS="quote"><B><FONT COLOR=red>Warning:</FONT></B> The socket method is insecure: not only are the texts of your changes transmitted over the network in unprotected form, it is also possible for anyone in the world to connect to the server process and read out the contents of your filesystem! (Of course, to do this they must understand the protocol that Unison uses to communicate between client and server, but all they need for this is a copy of the Unison sources.) The socket method is provided only for expert users with specific needs; everyone else should use the <CODE>ssh</CODE> method.</BLOCKQUOTE>To run Unison over a socket connection, you must start a Unison daemon process on the server. This process runs continuously, waiting for connections over a given socket from client machines running Unison and processing their requests in turn.<BR><BR>To start the daemon, type<PRE CLASS="verbatim">
|
||
|
|
unison -socket NNNN
|
||
|
|
</PRE>on the server machine, where <TT>NNNN</TT> is the socket number that the daemon should listen on for connections from clients. (<TT>NNNN</TT> can be any large number that is not being used by some other program; if <TT>NNNN</TT> is already in use, Unison will exit with an error message.) Note that paths specified by the client will be interpreted relative to the directory in which you start the server process; this behavior is different from the ssh case, where the path is relative to your home directory on the server.<BR><BR>Create a test directory <TT>a.tmp</TT> in your home directory on the client machine. Now type:<PRE>
|
||
|
|
unison a.tmp socket://<I>remotehostname</I>:NNNN/a.tmp
|
||
|
|
</PRE>The result should be that the entire directory <TT>a.tmp</TT> is propagated from the client to the server (<TT>a.tmp</TT> will be created on the server in the directory that the server was started from). After finishing the first synchronization, change a few files and try synchronizing again. You should see similar results as in the local case.<BR><BR>Since the socket method is not used by many people, its functionality is rather limited. For example, the server can only deal with one client at a time.<BR><BR><H3 CLASS="subsection"><A NAME="usingit"></A>Using Unison for All Your Files</H3>Once you are comfortable with the basic operation of Unison, you may find yourself wanting to use it regularly to synchronize your commonly used files. There are several possible ways of going about this:<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">Synchronize your whole home directory, using the Ignore facility (see the <A HREF="#ignore">Ignore</A> section) to avoid synchronizing temporary files and things that only belong on one host. <LI CLASS="li-enumerate">Create a subdirectory called <TT>shared</TT> (or <TT>current</TT>, or whatever) in your home directory on each host, and put all the files you want to synchronize into this directory. <LI CLASS="li-enumerate">Create a subdirectory called <TT>shared</TT> (or <TT>current</TT>, or whatever) in your home directory on each host, and put <EM>links to</EM> all the files you want to synchronize into this directory. Use the <TT>follow</TT> preference (see the <A HREF="#symlinks">Symbolic Links</A> section) to make Unison treat these links as transparent. <LI CLASS="li-enumerate">Make your home directory the root of the synchronization, but tell Unison to synchronize only some of the files and subdirectories within it on any given run. This can be accomplished by using the <TT>-path</TT> switch on the command line:<PRE>
|
||
|
|
unison /home/<I>username</I> ssh://<I>remotehost</I>//home/<I>username</I> -path shared
|
||
|
|
</PRE>The <TT>-path</TT> option can be used as many times as needed, to synchronize several files or subdirectories:<PRE>
|
||
|
|
unison /home/<I>username</I> ssh://<I>remotehost</I>//home/<I>username</I> <CODE>\</CODE>
|
||
|
|
-path shared <CODE>\</CODE>
|
||
|
|
-path pub <CODE>\</CODE>
|
||
|
|
-path .netscape/bookmarks.html
|
||
|
|
</PRE>These <CODE>-path</CODE> arguments can also be put in your preference file. See the <A HREF="#prefs">Preferences</A> section for an example.</OL>Most people find that they only need to maintain a profile (or profiles) on one of the hosts that they synchronize, since Unison is always initiated from this host. (For example, if you're synchronizing a laptop with a fileserver, you'll probably always run Unison on the laptop.) This is a bit different from the usual situation with asymmetric mirroring programs like <CODE>rdist</CODE>, where the mirroring operation typically needs to be initiated from the machine with the most recent changes. the <A HREF="#profile">Profile</A> section covers the syntax of Unison profiles, together with some sample profiles.<BR><BR>Some tips on improving Unison's performance can be found on the <A HREF="http://www.cis.upenn.edu/~bcpierce/unison/faq.html">Frequently Asked Questions page</A>.<BR><BR><H3 CLASS="subsection"><A NAME="usingmultiple"></A>Using Unison to Synchronize More Than Two Machines</H3>Unison is designed for synchronizing pairs of replicas. However, it is possible to use it to keep larger groups of machines in sync by performing multiple pairwise synchronizations.<BR><BR>If you need to do this, the most reliable way to set things up is to organize the machines into a “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.<BR><BR><H3 CLASS="subsection"><A NAME="further"></A>Going Further</H3>On-line documentation for the various features of Unison can be obtained either by typing<PRE CLASS="verbatim">
|
||
|
|
unison -doc topics
|
||
|
|
</PRE>at the command line, or by selecting the Help menu in the graphical user interface. The on-line information and the printed manual are essentially identical.<BR><BR>If you use Unison regularly, you should subscribe to one of the mailing lists, to receive announcements of new versions. See the <A HREF="#lists">Mailing Lists</A> section.<BR><BR><hr><H2 CLASS="section"><A NAME="basics"></A>Basic Concepts</H2>To understand how Unison works, it is necessary to discuss a few straightforward concepts. These concepts are developed more rigorously and at more length in a number of papers, available at <A HREF="http://www.cis.upenn.edu/~bcpierce/papers"><TT>http://www.cis.upenn.edu/~bcpierce/papers</TT></A>. But the informal presentation here should be enough for most users.<BR><BR><H3 CLASS="subsection"><A NAME="roots"></A>Roots</H3>A replica's <EM>root</EM> tells Unison where to find a set of files to be synchronized, either on the local machine or on a remote host. For example,<PRE>
|
||
|
|
<I>relative/path/of/root</I>
|
||
|
|
</PRE>specifies a local root relative to the directory where Unison is started, while<PRE>
|
||
|
|
/<I>absolute/path/of/root</I>
|
||
|
|
</PRE>specifies a root relative to the top of the local filesystem, independent of where Unison is running. Remote roots can begin with <CODE>ssh://</CODE>, <CODE>rsh://</CODE> to indicate that the remote server should be started with rsh or ssh:<PRE>
|
||
|
|
ssh://<I>remotehost</I>//<I>absolute/path/of/root</I>
|
||
|
|
rsh://<I>user</I>@<I>remotehost</I>/<I>relative/path/of/root</I>
|
||
|
|
</PRE>If the remote server is already running (in the socket mode), then the syntax<PRE>
|
||
|
|
socket://<I>remotehost</I>:<I>portnum</I>//<I>absolute/path/of/root</I>
|
||
|
|
socket://<I>remotehost</I>:<I>portnum</I>/<I>relative/path/of/root</I>
|
||
|
|
</PRE>is used to specify the hostname and the port that the client Unison should use to contact it.<BR><BR>The syntax for roots is based on that of URIs (described in RFC 2396). The full grammar is:<PRE>
|
||
|
|
<I>replica</I> ::= [<I>protocol</I>:]//[<I>user</I>@][<I>host</I>][:<I>port</I>][/<I>path</I>]
|
||
|
|
| <I>path</I>
|
||
|
|
|
||
|
|
<I>protocol</I> ::= file
|
||
|
|
| socket
|
||
|
|
| ssh
|
||
|
|
| rsh
|
||
|
|
|
||
|
|
<I>user</I> ::= [-_a-zA-Z0-9]+
|
||
|
|
|
||
|
|
<I>host</I> ::= [-_a-zA-Z0-9.]+
|
||
|
|
|
||
|
|
<I>port</I> ::= [0-9]+
|
||
|
|
</PRE>When <CODE>path</CODE> is given without any protocol prefix, the protocol is assumed to be <CODE>file:</CODE>. Under Windows, it is possible to synchronize with a remote directory using the <CODE>file:</CODE> protocol over the Windows Network Neighborhood. For example,<PRE CLASS="verbatim">
|
||
|
|
unison foo //host/drive/bar
|
||
|
|
</PRE>synchronizes the local directory <CODE>foo</CODE> with the directory <CODE>drive:\bar</CODE> on the machine <CODE>host</CODE>, provided that <CODE>host</CODE> is accessible via Network Neighborhood. When the <CODE>file:</CODE> protocol is used in this way, there is no need for a Unison server to be running on the remote host. However, running Unison this way is only a good idea if the remote host is reached by a very fast network connection, since the full contents of every file in the remote replica will have to be transferred to the local machine to detect updates.<BR><BR>The names of roots are <EM>canonized</EM> by Unison before it uses them to compute the names of the corresponding archive files, so <TT>//saul//home/bcpierce/common</TT> and <TT>//saul.cis.upenn.edu/common</TT> will be recognized as the same replica under different names.<BR><BR><H3 CLASS="subsection"><A NAME="paths"></A>Paths</H3>A <EM>path</EM> refers to a point <EM>within</EM> a set of files being synchronized; it is specified relative to the root of the replica.<BR><BR>Formally, a path is just a sequence of names, separated by <CODE>/</CODE>. Note that the path separator character is always a forward slash, no matter what operating system Unison is running on. Forward slashes are converted to backslashes as necessary when paths are converted to filenames in the local filesystem on a particular host. (For example, suppose that we run Unison on a Windows system, synchronizing the local root <CODE>c:\pierce</CODE> with the root <CODE>ssh://saul.cis.upenn.edu/home/bcpierce</CODE> on a Unix server. Then the path <CODE>current/todo.txt</CODE> refers to the file <CODE>c:\pierce\current\todo.txt</CODE> on the client and <CODE>/home/bcpierce/current/todo.txt</CODE> on the server.)<BR><BR>The empty path (i.e., the empty sequence of names) denotes the whole replica. Unison displays the empty path as “<CODE>[root]</CODE>.”<BR><BR>If <CODE>p</CODE> is a path and <CODE>q</CODE> is a path beginning with <CODE>p</CODE>, then <CODE>q</CODE> is said to be a <EM>descendant</EM> of <CODE>p</CODE>. (Each path is also a descendant of itself.)<BR><BR><H3 CLASS="subsection"><A NAME="updates"></A>What is an Update?</H3>The <EM>contents</EM> of a path <CODE>p</CODE> in a particular replica could be a file, a directory, a symbolic link, or absent (if <CODE>p</CODE> does not refer to anything at all in that replica). More specifically:<UL CLASS="itemize"><LI CLASS="li-itemize">If <CODE>p</CODE> refers to an ordinary file, then the contents of <CODE>p</CODE> are the actual contents of this file (a string of bytes) plus the current permission bits of the file. <LI CLASS="li-itemize">If <CODE>p</CODE> refers to a symbolic link, then the contents of <CODE>p</CODE> are just the string specifying where the link points. <LI CLASS="li-itemize">If <CODE>p</CODE> refers to a directory, then the contents of <CODE>p</CODE> are just the token “DIRECTORY” plus the current permission bits of the directory. <LI CLASS="li-itemize">If <CODE>p</CODE> does not refer to anything in this replica, then the contents of <CODE>p</CODE> are the token “ABSENT.”</UL>Unison keeps a record of the contents of each path after each successful synchronization of that path (i.e., it remembers the contents at the last moment when they were the same in the two replicas).<BR><BR>We say that a path is <EM>updated</EM> (in some replica) if its current contents are different from its contents the last time it was successfully synchronized. Note that whether a path is updated has nothing to do with its last modification time—Unison considers only the contents when determining whether an update has occurred. This means that touching a file without changing its contents will <EM>not</EM> be recognized as an update. A file can even be changed several times and then changed back to its original contents; as long as Unison is only run at the end of this process, no update will be recognized.<BR><BR>What Unison actually calculates is a close approximation to this definition;
|
||
|
|
rootalias = //<I>hostnameA</I>//<I>path-to-replicaA</I> -> //<I>hostnameB</I>//<I>path-to-replicaB</I>
|
||
|
|
</PRE>When calculating the name of the archive files for a given pair of roots, Unison replaces any root that matches the left-hand side of any rootalias rule by the corresponding right-hand side.<BR><BR>So, if you need to relocate a root on one of the hosts, you can add a rule of the form:<PRE>
|
||
|
|
rootalias = //<I>new-hostname</I>//<I>new-path</I> -> //<I>old-hostname</I>//<I>old-path</I>
|
||
|
|
</PRE><EM>Warning</EM>: The <CODE>rootalias</CODE> option is dangerous and should only be used if you are sure you know what you're doing. In particular, it should only be used if you are positive that either (1) both the original root and the new alias refer to the same set of files, or (2) the files have been relocated so that the original name is now invalid and will never be used again. (If the original root and the alias refer to different sets of files, Unison's update detector could get confused.) After introducing a new <CODE>rootalias</CODE>, it is a good idea to run Unison a few times interactively (with the <CODE>batch</CODE> flag off, etc.) and carefully check that things look reasonable—in particular, that update detection is working as expected.<BR><BR><H3 CLASS="subsection"><A NAME="prefs"></A>Preferences</H3>Many details of Unison's behavior are configurable by user-settable “preferences.”<BR><BR>Some preferences are boolean-valued; these are often called <EM>flags</EM>. Others take numeric or string arguments, indicated in the preferences list by <TT>n</TT> or <TT>xxx</TT>. Most of the string preferences can be given several times; the arguments are accumulated into a list internally.<BR><BR>There are two ways to set the values of preferences: temporarily, by providing command-line arguments to a particular run of Unison, or permanently, by adding commands to a <EM>profile</EM> in the <TT>.unison</TT> directory on the client host. The order of preferences (either on the command line or in preference files) is not significant. On the command line, preferences and other arguments (the profile name and roots) can be intermixed in any order.<BR><BR>To set the value of a preference <TT>p</TT> from the command line, add an argument <TT>-p</TT> (for a boolean flag) or <TT>-p n</TT> or <TT>-p xxx</TT> (for a numeric or string preference) anywhere on the command line. To set a boolean flag to <CODE>false</CODE> on the command line, use <TT>-p=false</TT>.<BR><BR>Here are all the preferences supported by Unison. This list can be obtained by typing <TT>unison -help</TT>.<BLOCKQUOTE CLASS="quote"><PRE CLASS="verbatim">
|
||
|
|
Usage: unison [options]
|
||
|
|
or unison root1 root2 [options]
|
||
|
|
or unison profilename [options]
|
||
|
|
|
||
|
|
Options:
|
||
|
|
-addprefsto xxx file to add new prefs to
|
||
|
|
-addversionno add version number to name of unison executable on server
|
||
|
|
-auto automatically accept default actions
|
||
|
|
-backup xxx add a pattern to the backup list
|
||
|
|
-backupcurrent xxx add a pattern to the backupcurrent list
|
||
|
|
-backupcurrentnot xxx add a pattern to the backupcurrentnot list
|
||
|
|
-backupdir xxx Directory for storing centralized backups
|
||
|
|
-backuplocation xxx where backups are stored ('local' or 'central')
|
||
|
|
-backupnot xxx add a pattern to the backupnot list
|
||
|
|
-backupprefix xxx prefix for the names of backup files
|
||
|
|
-backups keep backup copies of all files (see also 'backup')
|
||
|
|
-backupsuffix xxx a suffix to be added to names of backup files
|
||
|
|
-batch batch mode: ask no questions at all
|
||
|
|
-confirmbigdeletes request confirmation for whole-replica deletes
|
||
|
|
-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
|
||
|
|
-forcepartial xxx add a pattern to the forcepartial list
|
||
|
|
-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 (in some UIs)
|
||
|
|
-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
|
||
|
|
-mountpoint xxx abort if this path does not exist
|
||
|
|
-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
|
||
|
|
-preferpartial xxx add a pattern to the preferpartial list
|
||
|
|
-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
|
||
|
|
-selftest run internal tests and exit
|
||
|
|
-servercmd xxx name of unison executable on remote server
|
||
|
|
-showarchive show name of archive and 'true names' (for rootalias) of roots
|
||
|
|
-silent print nothing (except error messages)
|
||
|
|
-socket xxx act as a server on a socket
|
||
|
|
-sortbysize list changed files by size, not name
|
||
|
|
-sortfirst xxx add a pattern to the sortfirst list
|
||
|
|
-sortlast xxx add a pattern to the sortlast list
|
||
|
|
-sortnewfirst list new before changed files
|
||
|
|
-sshargs xxx other arguments (if any) for remote shell command
|
||
|
|
-sshcmd xxx path to the ssh executable
|
||
|
|
-terse suppress status messages
|
||
|
|
-testserver exit immediately after the connection to the server
|
||
|
|
-times synchronize modification times
|
||
|
|
-ui xxx select user interface ('text' or 'graphic'); command-line only
|
||
|
|
-version print version and exit
|
||
|
|
-xferbycopying optimize transfers using local copies, if possible
|
||
|
|
</PRE></BLOCKQUOTE>Here, in more detail, are what they do. Many are discussed in even greater detail in other sections of the manual.<DL CLASS="description" COMPACT=compact><DT CLASS="dt-description"><B>addprefsto <TT>xxx</TT></B><DD CLASS="dd-description">By default, new preferences added by Unison (e.g., new <CODE>ignore</CODE> clauses) will be appended to whatever preference file Unison was told to load at the beginning of the run. Setting the preference <TT>addprefsto <I>filename</I></TT> makes Unison add new preferences to the file named <TT><I>filename</I></TT> instead.<BR><BR><DT CLASS="dt-description"><B>addversionno </B><DD CLASS="dd-description">When this flag is set to <TT>true</TT>, Unison will use <TT>unison-<I>currentversionnumber</I></TT> instead of just <CODE>unison</CODE> as the remote server command. This allows multiple binaries for different versions of unison to coexist conveniently on the same server: whichever version is run on the client, the same version will be selected on the server.<BR><BR><DT CLASS="dt-description"><B>auto </B><DD CLASS="dd-description">When set to <TT>true</TT>, this flag causes the user interface to skip asking for confirmations on non-conflicting changes. (More precisely, when the user interface is done setting the propagation direction for one entry and is about to move to the next, it will skip over all non-conflicting entries and go directly to the next conflict.)<BR><BR><DT CLASS="dt-description"><B>backup <TT>xxx</TT></B><DD CLASS="dd-description">Including the preference <TT>-backup <I>pathspec</I></TT> causes Unison to keep backup files for each path that matches <TT><I>pathspec</I></TT>. These backup files are kept in the directory specified by the <CODE>backuplocation</CODE> preference. The backups are named according to the <CODE>backupprefix</CODE> and <CODE>backupsuffix</CODE> preferences. The number of versions that are kept is determined by the <CODE>maxbackups</CODE> preference.<BR><BR>The syntax of <TT><I>pathspec</I></TT> is described in the <A HREF="#pathspec">Path Specification</A> section.<BR><BR><DT CLASS="dt-description"><B>backupcurrent <TT>xxx</TT></B><DD CLASS="dd-description">Including the preference <TT>-backupcurrent <I>pathspec</I></TT> causes Unison to keep a backup of the <EM>current</EM> version of every file matching <TT><I>pathspec</I></TT>. This file will be saved as a backup with version number 000. Such backups can be used as inputs to external merging programs, for instance. See the documentatation for the <CODE>merge</CODE> preference. For more details, see the <A HREF="#merge">Merging Conflicting Versions</A> section.<BR><BR>The syntax of <TT><I>pathspec</I></TT> is described in the <A HREF="#pathspec">Path Specification</A> section.<BR><BR><DT CLASS="dt-description"><B>backupcurrentnot <TT>xxx</TT></B><DD CLASS="dd-description">Exceptions to <CODE>backupcurrent</CODE>, like the <CODE>ignorenot</CODE> preference.<BR><BR><DT CLASS="dt-description"><B>backupdir <TT>xxx</TT></B><DD CLASS="dd-description">If this preference is set, Unison will use it as the name of the directory used to store backup files specified by the <TT>backup</TT> preference, when <TT>backuplocation</TT> is set to <CODE>central</CODE>. It is checked <EM>after</EM> the <TT>UNISONBACKUPDIR</TT> environment variable.<BR><BR><DT CLASS="dt-description"><B>backuplocation <TT>xxx</TT></B><DD CLASS="dd-description">This preference determines whether backups should be kept locally, near the original files, or in a central directory specified by the <TT>backupdir</TT> preference. If set to <CODE>local</CODE>, backups will be kept in the same directory as the original files, and if set to <CODE>central</CODE>, <TT>backupdir</TT> will be used instead.<BR><BR><DT CLASS="dt-description"><B>backupnot <TT>xxx</TT></B><DD CLASS="dd-description">The values of this preference specify paths or individual files or regular expressions that should <EM>not</EM> be backed up, even if the <TT>backup</TT> preference selects them—i.e., it selectively overrides <TT>backup</TT>. The sam
|
||
|
|
p = true
|
||
|
|
</PRE>for a boolean flag or<PRE CLASS="verbatim">
|
||
|
|
p = <value>
|
||
|
|
</PRE>for a preference of any other type.<BR><BR>Whitespaces around <TT>p</TT> and <TT>xxx</TT> are ignored. A profile may also include blank lines and lines beginning with <TT>#</TT>; both are ignored.<BR><BR>When Unison starts, it first reads the profile and then the command line, so command-line options will override settings from the profile.<BR><BR>Profiles may also include lines of the form <TT>include <I>name</I></TT>, which will cause the file <TT><I>name</I></TT> (or <TT><I>name</I></TT><TT>.prf</TT>, if <TT><I>name</I></TT> does not exist in the <CODE>.unison</CODE> directory) to be read at the point, and included as if its contents, instead of the <TT>include</TT> line, was part of the profile. Include lines allows settings common to several profiles to be stored in one place.<BR><BR>A profile may include a preference `<TT>label = <I>desc</I></TT>' to provide a description of the options selected in this profile. The string <TT><I>desc</I></TT> is listed along with the profile name in the profile selection dialog, and displayed in the top-right corner of the main Unison window in the graphical user interface.<BR><BR>The graphical user-interface also supports one-key shortcuts for commonly used profiles. If a profile contains a preference of the form `<TT>key = <I>n</I></TT>', where <TT><I>n</I></TT> is a single digit, then pressing this digit key will cause Unison to immediately switch to this profile and begin synchronization again from scratch. In this case, all actions that have been selected for a set of changes currently being displayed will be discarded.<BR><BR><H3 CLASS="subsection"><A NAME="profileegs"></A>Sample Profiles</H3><H4 CLASS="subsubsection"><A NAME="minimalprofile"></A>A Minimal Profile</H4>Here is a very minimal profile file, such as might be found in <TT>.unison/default.prf</TT>:<PRE CLASS="verbatim">
|
||
|
|
# Roots of the synchronization
|
||
|
|
root = /home/bcpierce
|
||
|
|
root = ssh://saul//home/bcpierce
|
||
|
|
|
||
|
|
# Paths to synchronize
|
||
|
|
path = current
|
||
|
|
path = common
|
||
|
|
path = .netscape/bookmarks.html
|
||
|
|
</PRE><H4 CLASS="subsubsection"><A NAME="basicprofile"></A>A Basic Profile</H4>Here is a more sophisticated profile, illustrating some other useful features.<PRE CLASS="verbatim">
|
||
|
|
# Roots of the synchronization
|
||
|
|
root = /home/bcpierce
|
||
|
|
root = ssh://saul//home/bcpierce
|
||
|
|
|
||
|
|
# Paths to synchronize
|
||
|
|
path = current
|
||
|
|
path = common
|
||
|
|
path = .netscape/bookmarks.html
|
||
|
|
|
||
|
|
# Some regexps specifying names and paths to ignore
|
||
|
|
ignore = Name temp.*
|
||
|
|
ignore = Name *~
|
||
|
|
ignore = Name .*~
|
||
|
|
ignore = Path */pilot/backup/Archive_*
|
||
|
|
ignore = Name *.o
|
||
|
|
ignore = Name *.tmp
|
||
|
|
|
||
|
|
# Window height
|
||
|
|
height = 37
|
||
|
|
|
||
|
|
# Keep a backup copy of every file in a central location
|
||
|
|
backuplocation = central
|
||
|
|
backupdir = /home/bcpierce/backups
|
||
|
|
backup = Name *
|
||
|
|
backupprefix = $VERSION.
|
||
|
|
backupsuffix =
|
||
|
|
|
||
|
|
# Use this command for displaying diffs
|
||
|
|
diff = diff -y -W 79 --suppress-common-lines
|
||
|
|
|
||
|
|
# Log actions to the terminal
|
||
|
|
log = true
|
||
|
|
</PRE><H4 CLASS="subsubsection"><A NAME="powerprofile"></A>A Power-User Profile</H4>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 <TT>include</TT> mechanism can also be used to allow the same set of preference settings to be used with different roots.)<BR><BR>The collection of profiles implementing this scheme might look as follows. The file <TT>default.prf</TT> is empty except for an <TT>include</TT> directive:<PRE CLASS="verbatim">
|
||
|
|
# Include the contents of the file common
|
||
|
|
include common
|
||
|
|
</PRE>Note that the name of the common file is <TT>common</TT>, not <TT>common.prf</TT>; this prevents Unison from offering <TT>common</TT> as one of the list of profiles in the opening dialog (in the graphical UI).<BR><BR>The file <TT>common</TT> contains the real preferences:<PRE CLASS="verbatim">
|
||
|
|
# Roots of the synchronization
|
||
|
|
root = /home/bcpierce
|
||
|
|
root = ssh://saul//home/bcpierce
|
||
|
|
|
||
|
|
# (... other preferences ...)
|
||
|
|
|
||
|
|
# If any new preferences are added by Unison (e.g. 'ignore'
|
||
|
|
# preferences added via the graphical UI), then store them in the
|
||
|
|
# file 'common' rathen than in the top-level preference file
|
||
|
|
addprefsto = common
|
||
|
|
|
||
|
|
# Names and paths to ignore:
|
||
|
|
ignore = Name temp.*
|
||
|
|
ignore = Name *~
|
||
|
|
ignore = Name .*~
|
||
|
|
ignore = Path */pilot/backup/Archive_*
|
||
|
|
ignore = Name *.o
|
||
|
|
ignore = Name *.tmp
|
||
|
|
</PRE>Note that there are no <TT>path</TT> preferences in <TT>common</TT>. This means that, when we invoke Unison with the default profile (e.g., by typing '<TT>unison default</TT>' or just '<TT>unison</TT>' on the command line), the whole replicas will be synchronized. (If we <EM>never</EM> want to synchronize the whole replicas, then <TT>default.prf</TT> would instead include settings for all the paths that are usually synchronized.)<BR><BR>To synchronize just part of the replicas, Unison is invoked with an alternate preference file—e.g., doing '<TT>unison workingset</TT>', where the preference file <TT>workingset.prf</TT> contains<PRE CLASS="verbatim">
|
||
|
|
path = current/papers
|
||
|
|
path = Mail/inbox
|
||
|
|
path = Mail/drafts
|
||
|
|
include common
|
||
|
|
</PRE>causes Unison to synchronize just the listed subdirectories.<BR><BR>The <TT>key</TT> preference can be used in combination with the graphical UI to quickly switch between different sets of paths. For example, if the file <TT>mail.prf</TT> contains<PRE CLASS="verbatim">
|
||
|
|
path = Mail
|
||
|
|
batch = true
|
||
|
|
key = 2
|
||
|
|
include common
|
||
|
|
</PRE>then pressing 2 will cause Unison to look for updates in the <TT>Mail</TT> subdirectory and (because the <TT>batch</TT> flag is set) immediately propagate any that it finds.<BR><BR><H3 CLASS="subsection"><A NAME="backups"></A>Keeping Backups</H3>When Unison overwrites a file or directory by propagating a new version from the other replica, it can keep the old version around as a backup. There are several preferences that control precisely where these backups are stored and how they are named.<BR><BR>To enable backups, you must give one or more <CODE>backup</CODE> preferences. Each of these has the form<PRE CLASS="verbatim">
|
||
|
|
backup = <pathspec>
|
||
|
|
</PRE>where <CODE><pathspec></CODE> has the same form as for the <CODE>ignore</CODE> preference. For example,<PRE CLASS="verbatim">
|
||
|
|
backup = Name *
|
||
|
|
</PRE>causes Unison to keep backups of <EM>all</EM> files and directories. The <CODE>backupnot</CODE> preference can be used to give a few exceptions: it specifies which files and directories should <EM>not</EM> be backed up, even if they match the <CODE>backup</CODE> pathspec.<BR><BR>It is important to note that the <CODE>pathspec</CODE> is matched against the path that is being updated by Unison, not its descendants. For example, if you set <CODE>backup = Name *.txt</CODE> and then delete a whole directory named <CODE>foo</CODE> containing some text files, these files will not be backed up because Unison will just check that <CODE>foo</CODE> does not match <CODE>*.txt</CODE>. Similarly, if the directory itself happened to be called <CODE>foo.txt</CODE>, then the whole directory and all the files in it will be backed up, regardless of their names.<BR><BR>Backup files can be stored either <EM>centrally</EM> or <EM>locally</EM>. This behavior is controlled by the preference <CODE>backuplocation</CODE>, whose value must be either <CODE>central</CODE> or <CODE>local</CODE>. (The default is <CODE>central</CODE>.)<BR><BR>When backups are stored locally, they are kept in the same directory as the original.<BR><BR>When backups are stored centrally, the directory used to hold them is controlled by the preference <CODE>backupdir</CODE> and the environment variable <CODE>UNISONBACKUPDIR</CODE>. (The environment variable is checked first.) If neither of these are set, then the directory <CODE>.unison/backup</CODE> in the user's home directory is used.<BR><BR>The preference <CODE>maxbackups</CODE> controls how many previous versions of each file are kept (including the current version).<BR><BR>By default, backup files are named <CODE>.bak.VERSION.FILENAME</CODE>, where <CODE>FILENAME</CODE> is the original filename and <CODE>VERSION</CODE> is the backup number (1 for the most recent, 2 for the next most recent, etc.). This can be changed by setting the preferences <CODE>backupprefix</CODE> and/or <CODE>backupsuffix</CODE>. If desired, <CODE>backupprefix</CODE> may include a directory prefix; this can be used with <CODE>backuplocation = local</CODE> to put all backup files for each directory into a single subdirectory. For example, setting<PRE CLASS="verbatim">
|
||
|
|
backuplocation = local
|
||
|
|
backupprefix = .unison/$VERSION.
|
||
|
|
backupsuffix =
|
||
|
|
</PRE>will put all backups in a local subdirectory named <CODE>.unison</CODE>. Also, note that the string <CODE>$VERSION</CODE> in either <CODE>backupprefix</CODE> or <CODE>backupsuffix</CODE> (it must appear in one or the other) is replaced by the version number. This can be used, for example, to ensure that backup files retain the same extension as the originals.<BR><BR>For backward compatibility, the <CODE>backups</CODE> preference is also supported. It simply means <CODE>backup = Name *</CODE> and <CODE>backuplocation = local</CODE>.<BR><BR><H3 CLASS="subsection"><A NAME="merge"></A>Merging Conflicting Versions</H3>Unison can invoke external programs to merge conflicting versions of a file. The preference <CODE>merge</CODE> controls this process.<BR><BR>The <CODE>merge</CODE> preference may be given once or several times in a preference file (it can also be given on the command line, of course, but this tends to be awkward because of the spaces and special characters involved). Each instance of the preference looks like this:<PRE CLASS="verbatim">
|
||
|
|
merge = <PATHSPEC> -> <MERGECMD>
|
||
|
|
</PRE>The <CODE><PATHSPEC></CODE> here has exactly the same format as for the <CODE>ignore</CODE> preference (see the <A HREF="#pathspec">Path specification</A> section). For example, using “<CODE>Name *.txt</CODE>” as the <CODE><PATHSPEC></CODE> tells Unison that this command should be used whenever a file with extension <CODE>.txt</CODE> needs to be merged.<BR><BR>Many external merging programs require as inputs not just the two files that need to be merged, but also a file containing the <EM>last synchronized version</EM>. You can ask Unison to keep a copy of the last synchronized version for some files using the <CODE>backupcurrent</CODE> preference. This preference is used in exactly the same way as <CODE>backup</CODE> and its meaning is similar, except that it causes backups to be kept of the <EM>current</EM> contents of each file after it has been synchronized by Unison, rather than the <EM>previous</EM> contents that Unison overwrote. These backups are kept on <EM>both</EM> replicas in the same place as ordinary backup files—i.e. according to the <CODE>backuplocation</CODE> and <CODE>backupdir</CODE> preferences. They are named like the original files if <CODE>backupslocation</CODE> is set to 'central' and otherwise, Unison uses the <CODE>backupprefix</CODE> and <CODE>backupsuffix</CODE> preferences and assumes a version number 000 for these backups.<BR><BR>The <CODE><MERGECMD></CODE> part of the preference specifies what external command should be invoked to merge files at paths matching the <CODE><PATHSPEC></CODE>. Within this string, several special substrings are recognized; these will be substituted with appropriate values before invoking a sub-shell to execute the command.<UL CLASS="itemize"><LI CLASS="li-itemize"><CODE>CURRENT1</CODE> is replaced by the name of (a temporary copy of) the local variant of the file. <LI CLASS="li-itemize"><CODE>CURRENT2</CODE> is replaced by the name of a temporary file, into which the contents of the remote variant of the file have been transferred by Unison prior to performing the merge. <LI CLASS="li-itemize"><CODE>CURRENTARCH</CODE> is replaced by the name of the backed up copy of the original version of the file (i.e., the file saved by Unison if the current filename matches the path specifications for the <CODE>backupcurrent</CODE> preference, as explained above), if one exists. If no archive exists and <CODE>CURRENTARCH</CODE> appears in the merge command, then an error is signalled. <LI CLASS="li-itemize"><CODE>CURRENTARCHOPT</CODE> is replaced by the name of the backed up copy of the original version of the file (i.e., its state at the end of the last successful run of Unison), if one exists, or the empty string if no archive exists. <LI CLASS="li-itemize"><CODE>NEW</CODE> is replaced by the name of a temporary file that Unison expects to be written by the merge program when it finishes, giving the desired new contents of the file. <LI CLASS="li-itemize"><CODE>PATH</CODE> is replaced by the path (relative to the roots of the replicas) of the file being merged. <LI CLASS="li-itemize"><CODE>NEW1</CODE> and <CODE>NEW2</CODE> are replaced by the names of temporary files that Unison expects to be written by the merge program when it is only able to partially merge the originals; in this case, <CODE>NEW1</CODE> will be written back to the local replica and <CODE>NEW2</CODE> to the remote replica; <CODE>NEWARCH</CODE>, if present, will be used as the “last common state” of the replicas. (These three options are provided for later compatibility with the Harmony data synchronizer.)</UL>To accomodate the wide variety of programs that users might want to use for merging, Unison checks for several possible situations when the merge program exits:<UL CLASS="itemize"><LI CLASS="li-itemize">If the merge program exits with a non-zero status, then merge is considered to have failed and the replicas are not changed. <LI CLASS="li-itemize">If the file <CODE>NEW</CODE> has been created, it is written back to both replicas (and store
|
||
|
|
merge = Name *.txt -> diff3 CURRENT1 CURRENTARCH CURRENT2 -m > NEW
|
||
|
|
</PRE>will tell Unison to use the external <CODE>diff3</CODE> program for merging. Alternatively, users of <CODE>emacs</CODE> may find the following settings convenient:<PRE CLASS="verbatim">
|
||
|
|
merge = Name *.txt -> emacs -q --eval '(ediff-merge-files-with-ancestor
|
||
|
|
"CURRENT1" "CURRENT2" "CURRENTARCH" nil "NEW")'
|
||
|
|
</PRE>(These commands are displayed here on two lines to avoid running off the edge of the page. In your preference file, each command should be written on a single line.)<BR><BR>Users running emacs under windows may find something like this useful:<PRE CLASS="verbatim">
|
||
|
|
merge = Name * -> C:\Progra~1\Emacs\emacs\bin\emacs.exe -q --eval
|
||
|
|
"(ediff-files """CURRENT1""" """CURRENT2""")"
|
||
|
|
</PRE>Users running Mac OS X (you may need the Developer Tools installed to get the <TT>opendiff</TT> utility) may prefer<PRE CLASS="verbatim">
|
||
|
|
merge = Name *.txt -> opendiff CURRENT1 CURRENT2 -ancestor CURRENTARCH -merge NEW
|
||
|
|
</PRE>Here is a slightly more involved hack. The <TT>opendiff</TT> program can operate either with or without an archive file. A merge command of this form<PRE CLASS="verbatim">
|
||
|
|
merge = Name *.txt ->
|
||
|
|
if [ CURRENTARCHOPTx = x ];
|
||
|
|
then opendiff CURRENT1 CURRENT2 -merge NEW;
|
||
|
|
else opendiff CURRENT1 CURRENT2 -ancestor CURRENTARCHOPT -merge NEW;
|
||
|
|
fi
|
||
|
|
</PRE>(still all on one line in the preference file!) will test whether an archive file exists and use the appropriate variant of the arguments to <TT>opendiff</TT>.<BR><BR>Ordinarily, external merge programs are only invoked when Unison is <EM>not</EM> running in batch mode. To specify an external merge program that should be used no matter the setting of the <TT>batch</TT> flag, use the <TT>mergebatch</TT> preference instead of <TT>merge</TT>.<BLOCKQUOTE CLASS="quote"><I>Please post suggestions for other useful values of the </I><CODE><I>merge</I></CODE><I> preference to the <TT>unison-users</TT> mailing list—we'd like to give several examples here. </I></BLOCKQUOTE><H3 CLASS="subsection"><A NAME="ui"></A>The User Interface</H3>Both the textual and the graphical user interfaces are intended to be mostly self-explanatory. Here are just a few tricks:<UL CLASS="itemize"><LI CLASS="li-itemize">By default, when running on Unix the textual user interface will try to put the terminal into the “raw mode” so that it reads the input a character at a time rather than a line at a time. (This means you can type just the single keystroke “<CODE>></CODE>” to tell Unison to propagate a file from left to right, rather than “<CODE>></CODE> Enter.”)<BR><BR>There are some situations, though, where this will not work — for example, when Unison is running in a shell window inside Emacs. Setting the <CODE>dumbtty</CODE> preference will force Unison to leave the terminal alone and process input a line at a time.</UL><H3 CLASS="subsection"><A NAME="exit"></A>Exit code</H3>When running in the textual mode, Unison returns an exit status, which describes whether, and at which level, the synchronization was successful. The exit status could be useful when Unison is invoked from a script. Currently, there are four possible values for the exit status:<UL CLASS="itemize"><LI CLASS="li-itemize">0: successful synchronization; everything is up-to-date now. <LI CLASS="li-itemize">1: some files were skipped, but all file transfers were successful. <LI CLASS="li-itemize">2: non-fatal failures occurred during file transfer. <LI CLASS="li-itemize">3: a fatal error occurred, or the execution was interrupted.</UL>The graphical interface does not return any useful information through the exit status.<BR><BR><H3 CLASS="subsection"><A NAME="pathspec"></A>Path specification</H3>Several Unison preferences (e.g., <CODE>ignore</CODE>/<CODE>ignorenot</CODE>, <CODE>follow</CODE>, <CODE>sortfirst</CODE>/<CODE>sortlast</CODE>, <CODE>backup</CODE>, <CODE>merge</CODE>, etc.) specify individual paths or sets of paths. These preferences share a common syntax based on regular-expressions. Each preference is associated with a list of path patterns; the paths specified are those that match any one of the path pattern.<UL CLASS="itemize"><LI CLASS="li-itemize">Pattern preferences can be given on the command line, or, more often, stored in profiles, using the same syntax as other preferences. For example, a profile line of the form<PRE>
|
||
|
|
ignore = <TT><I>pattern</I></TT>
|
||
|
|
</PRE>adds <TT><I>pattern</I></TT> to the list of patterns to be ignored.<BR><BR><LI CLASS="li-itemize">Each <TT><I>pattern</I></TT> can have one of three forms. The most general form is a Posix extended regular expression introduced by the keyword <CODE>Regex</CODE>. (The collating sequences and character classes of full Posix regexps are not currently supported).<PRE>
|
||
|
|
Regex <TT><I>regexp</I></TT>
|
||
|
|
</PRE>For convenience, two other styles of pattern are also recognized:<PRE>
|
||
|
|
Name <TT><I>name</I></TT>
|
||
|
|
</PRE>matches any path in which the last component matches <TT><I>name</I></TT>, while<PRE>
|
||
|
|
Path <TT><I>path</I></TT>
|
||
|
|
</PRE>matches exactly the path <TT><I>path</I></TT>. The <TT><I>name</I></TT> and <TT><I>path</I></TT> arguments of the latter forms of patterns are <EM>not</EM> regular expressions. Instead, standard “globbing” conventions can be used in <TT><I>name</I></TT> and <TT><I>path</I></TT>:<UL CLASS="itemize"><LI CLASS="li-itemize">a <CODE>*</CODE> matches any sequence of characters not including <CODE>/</CODE> (and not beginning with <CODE>.</CODE>, when used at the beginning of a <TT><I>name</I></TT>) <LI CLASS="li-itemize">a <CODE>?</CODE> matches any single character except <CODE>/</CODE> (and leading <CODE>.</CODE>) <LI CLASS="li-itemize"><CODE>[xyz]</CODE> matches any character from the set {<TT><I>x</I></TT>, <TT><I>y</I></TT>, <TT><I>z</I></TT> } <LI CLASS="li-itemize"><CODE>{a,bb,ccc}</CODE> matches any one of <CODE>a</CODE>, <CODE>bb</CODE>, or <CODE>ccc</CODE>.</UL><LI CLASS="li-itemize">The path separator in path patterns is always the forward-slash character “/” — even when the client or server is running under Windows, where the normal separator character is a backslash. This makes it possible to use the same set of path patterns for both Unix and Windows file systems.</UL>Some examples of path patterns appear in the <A HREF="#ignore">Ignoring Paths</A> section.<BR><BR><H3 CLASS="subsection"><A NAME="ignore"></A>Ignoring Paths</H3>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 <A HREF="#pathspec">Path Patterns</A> section.<BR><BR>For example, the following pattern will make Unison ignore any path containing the name <CODE>CVS</CODE> or a name ending in <CODE>.cmo</CODE>:<PRE CLASS="verbatim">
|
||
|
|
ignore = Name {CVS,*.cmo}
|
||
|
|
</PRE>The next pattern makes Unison ignore the path <CODE>a/b</CODE>:<PRE CLASS="verbatim">
|
||
|
|
ignore = Path a/b
|
||
|
|
</PRE>Path patterns do <EM>not</EM> skip filesnames beginning with <CODE>.</CODE> (as Name patterns do). For example,<PRE CLASS="verbatim">
|
||
|
|
ignore = Path */tmp
|
||
|
|
</PRE>will include <CODE>.foo/tmp</CODE> in the set of ignore directories, as it is a path, not a name, that is ignored.<BR><BR>The following pattern makes Unison ignore any path beginning with <CODE>a/b</CODE> and ending with a name ending by <CODE>.ml</CODE>.<PRE CLASS="verbatim">
|
||
|
|
ignore = Regex a/b/.*\.ml
|
||
|
|
</PRE>Note that regular expression patterns are “anchored”: they must match the whole path, not just a substring of the path.<BR><BR>Here are a few extra points regarding the <TT>ignore</TT> preference.<UL CLASS="itemize"><LI CLASS="li-itemize">If a directory is ignored, all its descendents will be too.<BR><BR><LI CLASS="li-itemize">The user interface provides some convenient commands for adding new patterns to be ignored. To ignore a particular file, select it and press “<TT>i</TT>”. To ignore all files with the same extension, select it and press “<TT>E</TT>” (with the shift key). To ignore all files with the same name, no matter what directory they appear in, select it and press “<TT>N</TT>”. These new patterns become permanent: they are immediately added to the current profile on disk.<BR><BR><LI CLASS="li-itemize">If you use the <CODE>include</CODE> directive to include a common collection of preferences in several top-level preference files, you will probably also want to set the <CODE>addprefsto</CODE> preference to the name of this file. This will cause any new ignore patterns that you add from inside Unison to be appended to this file, instead of whichever top-level preference file you started Unison with.<BR><BR><LI CLASS="li-itemize">Ignore patterns can also be specified on the command line, if you like (this is probably not very useful), using an option like <CODE>-ignore 'Name temp.txt'</CODE>.<BR><BR><LI CLASS="li-itemize">Be careful about renaming directories containing ignored files. Because Unison understands the rename as a delete plus a create, any ignored files in the directory will be lost (since they are invisible to Unison and therefore they do not get recreated in the new version of the directory).<BR><BR><LI CLASS="li-itemize">There is also an <CODE>ignorenot</CODE> preference, which specifies a set of patterns for paths that should <EM>not</EM> be ignored, even if they match an <CODE>ignore</CODE> pattern. However, the interaction of these two sets of patterns can be a little tricky. Here is exactly how it works:<UL CLASS="itemize"><LI CLASS="li-itemize">Unison starts detecting updates from the root of the replicas—i.e., from the empty path. If the empty path matches an <CODE>ignore</CODE> pattern and does not match an <CODE>ignorenot</CODE> pattern, then the whole replica will be ignored. (For this reason, it is not a good idea to include <CODE>Name *</CODE> as an <CODE>ignore</CODE> pattern. If you want to ignore everything except a certain set of files, use <CODE>Name ?*</CODE>.) <LI CLASS="li-itemize">If the root is a directory, Unison continues looking for updates in all the immediate children of the root. Again, if the name of some child matches an <CODE>ignore</CODE> pattern and does not match an <CODE>ignorenot</CODE> pattern, then this whole path <EM>including everything below it</EM> will be ignored. <LI CLASS="li-itemize">If any of the non-ignored children are directories, then the process continues recursively.</UL></UL><H3 CLASS="subsection"><A NAME="symlinks"></A>Symbolic Links</H3>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.<BR><BR>It is sometimes useful to treat a symbolic link “transparently,” acting as though whatever it points to were physically <EM>in</EM> the replica at the point where the symbolic link appears. To tell Unison to treat a link in this manner, add a line of the form<PRE>
|
||
|
|
follow = <TT><I>pathspec</I></TT>
|
||
|
|
</PRE>to the profile, where <TT><I>pathspec</I></TT> is a path pattern as described in the <A HREF="#pathspec">Path Patterns</A> section.<BR><BR>Windows file systems do not support symbolic links; Unison will refuse to propagate an opaque symbolic link from Unix to Windows and flag the path as erroneous. When a Unix replica is to be synchronized with a Windows system, all symbolic links should match either an <CODE>ignore</CODE> pattern or a <CODE>follow</CODE> pattern.<BR><BR><H3 CLASS="subsection"><A NAME="perms"></A>Permissions</H3>Synchronizing the permission bits of files is slightly tricky when two different filesytems are involved (e.g., when synchronizing a Windows client and a Unix server). In detail, here's how it works:<UL CLASS="itemize"><LI CLASS="li-itemize">When the permission bits of an existing file or directory are changed, the values of those bits that make sense on <EM>both</EM> operating systems will be propagated to the other replica. The other bits will not be changed. <LI CLASS="li-itemize">When a newly created file is propagated to a remote replica, the permission bits that make sense in both operating systems are also propagated. The values of the other bits are set to default values (they are taken from the current umask, if the receiving host is a Unix system). <LI CLASS="li-itemize">For security reasons, the Unix <CODE>setuid</CODE> and <CODE>setgid</CODE> bits are not propagated. <LI CLASS="li-itemize">The Unix owner and group ids are not propagated. (What would this mean, in general?) All files are created with the owner and group of the server process.</UL><H3 CLASS="subsection"><A NAME="crossplatform"></A>Cross-Platform Synchronization</H3>If you use Unison to synchronize files between Windows and Unix systems, there are a few special issues to be aware of.<BR><BR><B>Case conflicts.</B> In Unix, filenames are case sensitive: <TT>foo</TT> and <TT>FOO</TT> can refer to different files. In Windows, on the other hand, filenames are not case sensitive: <TT>foo</TT> and <TT>FOO</TT> can only refer to the same file. This means that a Unix <TT>foo</TT> and <TT>FOO</TT> cannot be synchronized onto a Windows system — 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.<BR><BR>You can deal with a case conflict in a couple of ways. If you need to have both files on the Windows system, your only choice is to rename one of the Unix files to avoid the case conflict, and re-synchronize. If you don't need the files on the Windows system, you can simply disregard Unison's warning message, and go ahead with the synchronization; Unison won't touch those files. If you don't want to see the warning on each synchronization, you can tell Unison to ignore the files (see the <A HREF="#ignore">Ignore</A> section).<BR><BR><B>Illegal filenames.</B> Unix allows some filenames that are illegal in Windows. For example, colons (`:') are not allowed in Windows filenames, but they are legal in Unix filenames. This means that a Unix file <TT>foo:bar</TT> can't be synchronized to a Windows system. As with case conflicts, Unison detects this situation for you, and you have the same options: you can either rename the Unix file and re-synchronize, or you can ignore it.<BR><BR><H3 CLASS="subsection"><A NAME="speed"></A>Slow Links</H3>Unison is built to run well even over relatively slow links such as modems and DSL connections.<BR><BR>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 (<A HREF="http://samba.anu.edu.au/rsync/"><TT>http://samba.anu.edu.au/rsync/</TT></A>).<BR><BR>If you are using Unison with <TT>ssh</TT>, you may get some speed improvement by enabling <TT>ssh</TT>'s compression feature. Do this by adding the option “<TT>-rshargs -C</TT>” to the command line or “<TT>rshargs =
|
||
|
|
mountpoint = /mnt/foo
|
||
|
|
</PRE>in your preference file will cause Unison to check, after it finishes detecting updates, that something actually exists at the path <CODE>/mnt/foo</CODE> on both replicas; if it does not, the Unison run will abort.<BR><BR><H3 CLASS="subsection"><A NAME="click"></A>Click-starting Unison</H3>On Windows NT/2k/XP systems, the graphical version of Unison can be invoked directly by clicking on its icon. On Windows 95/98 systems, click-starting also works, <EM>as long as you are not using ssh</EM>. Due to an incompatibility with ocaml and Windows 95/98 that is not under our control, you must start Unison from a DOS window in Windows 95/98 if you want to use ssh.<BR><BR>When you click on the Unison icon, two windows will be created: Unison's regular window, plus a console window, which is used only for giving your password to ssh (if you do not use ssh to connect, you can ignore this window). When your password is requested, you'll need to activate the console window (e.g., by clicking in it) before typing. If you start Unison from a DOS window, Unison's regular window will appear and you will type your password in the DOS window you were using.<BR><BR>To use Unison in this mode, you must first create a profile (see the <A HREF="#profile">Profile</A> section). Use your favorite editor for this.<BR><BR><hr><H2 CLASS="section"><A NAME="ssh"></A>Installing Ssh</H2><EM>Warning: These instructions may be out of date. More current information can be found the </EM><A HREF="http://alliance.seas.upenn.edu/ bcpierce/wiki/index.php?n=Main.UnisonFAQOSSpecific"><EM>Unison Wiki</EM></A><EM>.</EM><BR><BR>Your local host will need just an ssh client; the remote host needs an ssh server (or daemon), which is available on Unix systems. Unison is known to work with ssh version 1.2.27 (Unix) and version 1.2.14 (Windows); other versions may or may not work.<BR><BR><H3 CLASS="subsection"><A NAME="ssh-unix"></A>Unix</H3>Most modern Unix installations come with <CODE>ssh</CODE> pre-installed.<BR><BR><H3 CLASS="subsection"><A NAME="ssh-win"></A>Windows</H3>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.<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">Download an <CODE>ssh</CODE> executable.<BR><BR>Warning: there are many implementations and ports of ssh for Windows, and not all of them will work with Unison. We have gotten Unison to work with Cygwin's port of openssh, and we suggest you try that one first. Here's how to install it:<OL CLASS="enumerate" type=a><LI CLASS="li-enumerate">First, create a new folder on your desktop to hold temporary installation files. It can have any name you like, but in these instructions we'll assume that you call it <CODE>Foo</CODE>. <LI CLASS="li-enumerate">Direct your web browser to www.cygwin.com, and click on the “Install now!” link. This will download a file, <CODE>setup.exe</CODE>; save it in the directory <CODE>Foo</CODE>. The file <CODE>setup.exe</CODE> is a small program that will download the actual install files from the Internet when you run it. <LI CLASS="li-enumerate">Start <CODE>setup.exe</CODE> (by double-clicking). This brings up a series of dialogs that you will have to go through. Select “Install from Internet.” For “Local Package Directory” select the directory <CODE>Foo</CODE>. For “Select install root directory” we recommend that you use the default, <CODE>C:\cygwin</CODE>. The next dialog asks you to select the way that you want to connect to the network to download the installation files; we have used “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.<BR><BR>Next you are asked to select which packages to install. The default settings in this dialog download a lot of packages that are not strictly necessary to run Unison with ssh. If you d
|
||
|
|
http://opensores.thebunker.net/pub/mirrors/ssh/contrib/ssh-1.2.14-win32bin.zip
|
||
|
|
</PRE><BR><BR><LI CLASS="li-enumerate">You must set the environment variables HOME and PATH. Ssh will create a directory <CODE>.ssh</CODE> in the directory given by HOME, so that it has a place to keep data like your public and private keys. PATH must be set to include the Cygwin <CODE>bin</CODE> directory, so that Unison can find the ssh executable.<UL CLASS="itemize"><LI CLASS="li-itemize">On Windows 95/98, add the lines<PRE CLASS="verbatim">
|
||
|
|
set PATH=%PATH%;<SSHDIR>
|
||
|
|
set HOME=<HOMEDIR>
|
||
|
|
</PRE>to the file <CODE>C:\AUTOEXEC.BAT</CODE>, where <CODE><HOMEDIR></CODE> is the directory where you want ssh to create its <CODE>.ssh</CODE> directory, and <CODE><SSHDIR></CODE> is the directory where the executable <CODE>ssh.exe</CODE> is stored; if you've installed Cygwin in the default location, this is <CODE>C:\cygwin\bin</CODE>. You will have to reboot your computer to take the changes into account. <LI CLASS="li-itemize">On Windows NT/2k/XP, open the environment variables dialog box:<UL CLASS="itemize"><LI CLASS="li-itemize">Windows NT: My Computer/Properties/Environment <LI CLASS="li-itemize">Windows 2k: My Computer/Properties/Advanced/Environment variables</UL>then select Path and edit its value by appending <CODE>;<SSHDIR></CODE> to it, where <CODE><SSHDIR></CODE> is the full name of the directory that includes the ssh executable; if you've installed Cygwin in the default location, this is <CODE>C:\cygwin\bin</CODE>.</UL><LI CLASS="li-enumerate">Test ssh from a DOS shell by typing<PRE CLASS="verbatim">
|
||
|
|
ssh <remote host> -l <login name>
|
||
|
|
</PRE>You should get a prompt for your password on <CODE><remote host></CODE>, followed by a working connection. <LI CLASS="li-enumerate">Note that <CODE>ssh-keygen</CODE> 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. <LI CLASS="li-enumerate">You should now be able to use Unison with an ssh connection. If you are logged in with a different user name on the local and remote hosts, provide your remote user name when providing the remote root (i.e., <CODE>//username@host/path...</CODE>).</OL><hr><H2 CLASS="section"><A NAME="news"></A>Changes in Version 2.27.57</H2>Changes since 2.17:<UL CLASS="itemize"><LI CLASS="li-itemize">Major rewrite and cleanup of the whole Mac OS X graphical user interface by Craig Federighi. Thanks, Craig!!!<BR><BR><LI CLASS="li-itemize">Several small fixes to the GTK2 UI to make it work better under Windows [thanks to Karl M for these].<BR><BR><LI CLASS="li-itemize">The backup functionality has been completely rewritten. The external interface has not changed, but numerous bugs, irregular behaviors, and cross-platform inconsistencies have been corrected.<BR><BR><LI CLASS="li-itemize">The Unison project now accepts donations via PayPal. You can find a link to the donation page on the <A HREF="http://www.cis.upenn.edu/ bcpierce/unison/lists.html">Unison home page</A>.<BR><BR><LI CLASS="li-itemize">Some important safety improvements:<UL CLASS="itemize"><LI CLASS="li-itemize">Added a new <CODE>mountpoint</CODE> preference, which can be used to specify a path that must exist in both replicas at the end of update detection (otherwise Unison aborts). This can be used to avoid potentially dangerous situations when Unison is used with removable media such as external hard drives and compact flash cards.<BR><BR><LI CLASS="li-itemize">The confirmation of “big deletes” is now controlled by a boolean preference <CODE>confirmbigdeletes</CODE>. Default is true, which gives the same behavior as previously. (This functionality is at least partly superceded by the <CODE>mountpoint</CODE> preference, but it has been left in place in case it is useful to some people.)<BR><BR><LI CLASS="li-itemize">If Unison is asked to “follow” a symbolic link but there is nothing at the other end of the link, it will now flag this path as an error, rather than treating the symlink itself as missing or deleted. This avoids a potentially dangerous situation where a followed symlink points to an external filesystem that might be offline when Unison is run (whereupon Unison would cheerfully delete the corresponding files in the other replica!).</UL><BR><BR><LI CLASS="li-itemize">Smaller changes:<UL CLASS="itemize"><LI CLASS="li-itemize">Added <CODE>forcepartial</CODE> and <CODE>preferpartial</CODE> preferences, which behave like <CODE>force</CODE> and <CODE>prefer</CODE> but can be specified on a per-path basis. [Thanks to Alan Schmitt for this.]<BR><BR><LI CLASS="li-itemize">A bare-bones self test feature was added, which runs unison through some of its paces and checks that the results are as expected. The coverage of the tests is still very limited, but the facility has already been very useful in debugging the new backup functionality (especially in exposing some subtle cross-platform issues).<BR><BR><LI CLASS="li-itemize">Refined debugging code so that the verbosity of individual modules can be controlled separately. Instead of just putting '-debug verbose' on the command line, you can put '-debug update+', which causes all the extra messages in the Update module, but not other modules, to be printed. Putting '-debug verbose' causes all modules to print with maximum verbosity.<BR><BR><LI CLASS="li-itemize">Removed <CODE>mergebatch</CODE> preference. (It never seemed very useful, and its semantics were confusing.)<BR><BR><LI CLASS="li-itemize">Rewrote some of the merging functionality, for better cooperation with external Harmony instances.<BR><BR><LI CLASS="li-itemize">Changed
|
||
|
|
svn co https://cvs.cis.upenn.edu:3690/svnroot/unison/
|
||
|
|
</PRE>We will also continue to export a “developer tarball” of the current (modulo one day) sources in the web export directory. To receive commit logs for changes to the sources, subscribe to the <CODE>unison-hackers</CODE> list (<A HREF="http://www.cis.upenn.edu/ bcpierce/unison/lists.html"><TT>http://www.cis.upenn.edu/ bcpierce/unison/lists.html</TT></A>).<BR><BR><LI CLASS="li-itemize">Text user interface:<UL CLASS="itemize"><LI CLASS="li-itemize">Substantial reworking of the internal logic of the text UI to make it a bit easier to modify. <LI CLASS="li-itemize">The <TT>dumbtty</TT> flag in the text UI is automatically set to true if the client is running on a Unix system and the <TT>EMACS</TT> environment variable is set to anything other than the empty string.</UL><BR><BR><LI CLASS="li-itemize">Native OS X gui:<UL CLASS="itemize"><LI CLASS="li-itemize">Added a synchronize menu item with keyboard shortcut <LI CLASS="li-itemize">Added a merge menu item, still needs to be debugged <LI CLASS="li-itemize">Fixes to compile for Panther <LI CLASS="li-itemize">Miscellaneous improvements and bugfixes</UL><BR><BR><LI CLASS="li-itemize">Small changes:<UL CLASS="itemize"><LI CLASS="li-itemize">Changed the filename checking code to apply to Windows only, instead of OS X as well. <LI CLASS="li-itemize">Finder flags now synchronized <LI CLASS="li-itemize">Fallback in copy.ml for filesystem that do not support <CODE>O_EXCL</CODE> <LI CLASS="li-itemize">Changed buffer size for local file copy (was highly inefficient with synchronous writes) <LI CLASS="li-itemize">Ignore chmod failure when deleting a directory <LI CLASS="li-itemize">Fixed assertion failure when resolving a conflict content change / permission changes in favor of the content change. <LI CLASS="li-itemize">Workaround for transferring large files using rsync. <LI CLASS="li-itemize">Use buffered I/O for files (this is the only way to open files in binary mode under Cygwin). <LI CLASS="li-itemize">On non-Cygwin Windows systems, the UNISON environment variable is now checked first to determine where to look for Unison's archive and preference files, followed by <CODE>HOME</CODE> and <CODE>USERPROFILE</CODE> in that order. On Unix and Cygwin systems, <CODE>HOME</CODE> is used. <LI CLASS="li-itemize">Generalized <CODE>diff</CODE> preference so that it can be given either as just the command name to be used for calculating diffs or else a whole command line, containing the strings <CODE>CURRENT1</CODE> and <CODE>CURRENT2</CODE>, which will be replaced by the names of the files to be diff'ed before the command is called. <LI CLASS="li-itemize">Recognize password prompts in some newer versions of ssh.</UL></UL>Changes since 2.9.20:<UL CLASS="itemize"><LI CLASS="li-itemize"><B>Incompatible change:</B> Archive format has changed. <LI CLASS="li-itemize">Major functionality changes:<UL CLASS="itemize"><LI CLASS="li-itemize">Major tidying and enhancement of 'merge' functionality. The main user-visible change is that the external merge program may either write the merged output to a single new file, as before, or it may modify one or both of its input files, or it may write <EM>two</EM> new files. In the latter cases, its modifications will be copied back into place on both the local and the remote host, and (if the two files are now equal) the archive will be updated appropriately. More information can be found in the user manual. Thanks to Malo Denielou and Alan Schmitt for these improvements.<BR><BR>Warning: the new merging functionality is not completely compatible with old versions! Check the manual for details.<BR><BR><LI CLASS="li-itemize">Files larger than 2Gb are now supported.<BR><BR><LI CLASS="li-itemize">Added preliminary (and still somewhat experimental) support for the Apple OS X operating system.<UL CLASS="itemize"><LI CLASS="li-itemize">Resource forks should be transferred correctly. (See the manual for details of how this works when synchronizing HFS with non-HFS volumes.) Synchronization of file type and creator information is also supported. <LI CL
|
||
|
|
merge = diff3 -m CURRENT1 OLD CURRENT2 > NEW
|
||
|
|
</PRE>will tell Unison to use the external <CODE>diff3</CODE> program for merging.<BR><BR>A large number of external merging programs are available. For example, <CODE>emacs</CODE> users may find the following convenient:<PRE CLASS="verbatim">
|
||
|
|
merge2 = emacs -q --eval '(ediff-merge-files "CURRENT1" "CURRENT2"
|
||
|
|
nil "NEW")'
|
||
|
|
merge = emacs -q --eval '(ediff-merge-files-with-ancestor
|
||
|
|
"CURRENT1" "CURRENT2" "OLD" nil "NEW")'
|
||
|
|
</PRE>(These commands are displayed here on two lines to avoid running off the edge of the page. In your preference file, each should be written on a single line.)<BR><BR><LI CLASS="li-itemize">If the external program exits without leaving any file at the path <CODE>NEW</CODE>, Unison considers the merge to have failed. If the merge program writes a file called <CODE>NEW</CODE> but exits with a non-zero status code, then Unison considers the merge to have succeeded but to have generated conflicts. In this case, it attempts to invoke an external editor so that the user can resolve the conflicts. The value of the <CODE>editor</CODE> preference controls what editor is invoked by Unison. The default is <CODE>emacs</CODE>.<BR><BR><LI CLASS="li-itemize">Please send us suggestions for other useful values of the <CODE>merge2</CODE> and <CODE>merge</CODE> preferences – we'd like to give several examples in the manual.</UL></UL><BR><BR><LI CLASS="li-itemize">Smaller changes:<UL CLASS="itemize"><LI CLASS="li-itemize">When one preference file includes another, unison no longer adds the suffix '<CODE>.prf</CODE>' to the included file by default. If a file with precisely the given name exists in the .unison directory, it will be used; otherwise Unison will add <CODE>.prf</CODE>, as it did before. (This change means that included preference files can be named <CODE>blah.include</CODE> instead of <CODE>blah.prf</CODE>, so that unison will not offer them in its 'choose a preference file' dialog.) <LI CLASS="li-itemize">For Linux systems, we now offer both a statically linked and a dynamically linked executable. The static one is larger, but will probably run on more systems, since it doesn't depend on the same versions of dynamically linked library modules being available. <LI CLASS="li-itemize">Fixed the <CODE>force</CODE> and <CODE>prefer</CODE> preferences, which were getting the propagation direction exactly backwards. <LI CLASS="li-itemize">Fixed a bug in the startup code that would cause unison to crash when the default profile (<CODE>~/.unison/default.prf</CODE>) does not exist. <LI CLASS="li-itemize">Fixed a bug where, on the run when a profile is first created, Unison would confusingly display the roots in reverse order in the user interface.</UL><BR><BR><LI CLASS="li-itemize">For developers:<UL CLASS="itemize"><LI CLASS="li-itemize">We've added a module dependency diagram to the source distribution, in <CODE>src/DEPENDENCIES.ps</CODE>, to help new prospective developers with navigating the code.</UL></UL>Changes since 2.6.11:<UL CLASS="itemize"><LI CLASS="li-itemize"><B>Incompatible change:</B> Archive format has changed.<BR><BR><LI CLASS="li-itemize"><B>Incompatible change:</B> The startup sequence has been completely rewritten and greatly simplified. The main user-visible change is that the <CODE>defaultpath</CODE> preference has been removed. Its effect can be approximated by using multiple profiles, with <CODE>include</CODE> directives to incorporate common settings. All uses of <CODE>defaultpath</CODE> in existing profiles should be changed to <CODE>path</CODE>.<BR><BR>Another change in startup behavior that will affect some users is that it is no longer possible to specify roots <EM>both</EM> in the profile <EM>and</EM> on the command line.<BR><BR>You can achieve a similar effect, though, by breaking your profile into two:<PRE CLASS="verbatim">
|
||
|
|
|
||
|
|
default.prf =
|
||
|
|
root = blah
|
||
|
|
root = foo
|
||
|
|
include common
|
||
|
|
|
||
|
|
common.prf =
|
||
|
|
<everything else>
|
||
|
|
</PRE>Now do<PRE CLASS="verbatim">
|
||
|
|
unison common root1 root2
|
||
|
|
</PRE>when you want to specify roots explicitly.<BR><BR><LI CLASS="li-itemize">The <CODE>-prefer</CODE> and <CODE>-force</CODE> options have been extended to allow users to specify that files with more recent modtimes should be propagated, writing either <CODE>-prefer newer</CODE> or <CODE>-force newer</CODE>. (For symmetry, Unison will also accept <CODE>-prefer older</CODE> or <CODE>-force older</CODE>.) The <CODE>-force older/newer</CODE> options can only be used when <CODE>-times</CODE> is also set.<BR><BR>The graphical user interface provides access to these facilities on a one-off basis via the <CODE>Actions</CODE> menu.<BR><BR><LI CLASS="li-itemize">Names of roots can now be “aliased” to allow replicas to be relocated without changing the name of the archive file where Unison stores information between runs. (This feature is for experts only. See the “Archive Files” section of the manual for more information.)<BR><BR><LI CLASS="li-itemize">Graphical user-interface:<UL CLASS="itemize"><LI CLASS="li-itemize">A new command is provided in the Synchronization menu for switching to a new profile without restarting Unison from scratch. <LI CLASS="li-itemize">The GUI also supports one-key shortcuts for commonly used profiles. If a profile contains a preference of the form '<CODE>key = n</CODE>', where <CODE>n</CODE> is a single digit, then pressing this key will cause Unison to immediately switch to this profile and begin synchronization again from scratch. (Any actions that may have been selected for a set of changes currently being displayed will be discarded.)<BR><BR><LI CLASS="li-itemize">Each profile may include a preference '<CODE>label = <string></CODE>' giving a descriptive string that described the options selected in this profile. The string is listed along with the profile name in the profile selection dialog, and displayed in the top-right corner of the main Unison window.</UL><BR><BR><LI CLASS="li-itemize">Minor:<UL CLASS="itemize"><LI CLASS="li-itemize">Fixed a bug that would sometimes cause the 'diff' display to order the files backwards relative to the main user interface. (Thanks to Pascal Brisset for this fix.) <LI CLASS="li-itemize">On Unix systems, the graphical version of Unison will check the <CODE>DISPLAY</CODE> variable and, if it is not set, automatically fall back to the textual user interface. <LI CLASS="li-itemize">Synchronization paths (<CODE>path</CODE> preferences) are now matched against the ignore preferences. So if a path is both specified in a <CODE>path</CODE> preference and ignored, it will be skipped. <LI CLASS="li-itemize">Numerous other bugfixes and small improvements.</UL></UL>Changes since 2.6.1:<UL CLASS="itemize"><LI CLASS="li-itemize">The synchronization of modification times has been disabled for directories.<BR><BR><LI CLASS="li-itemize">Preference files may now include lines of the form <CODE>include <name></CODE>, which will cause <CODE>name.prf</CODE> to be read at that point.<BR><BR><LI CLASS="li-itemize">The synchronization of permission between Windows and Unix now works properly.<BR><BR><LI CLASS="li-itemize">A binding <CODE>CYGWIN=binmode</CODE> in now added to the environment so that the Cygwin port of OpenSSH works properly in a non-Cygwin context.<BR><BR><LI CLASS="li-itemize">The <CODE>servercmd</CODE> and <CODE>addversionno</CODE> preferences can now be used together: <CODE>-addversionno</CODE> appends an appropriate <CODE>-NNN</CODE> to the server command, which is found by using the value of the <CODE>-servercmd</CODE> preference if there is one, or else just <CODE>unison</CODE>.<BR><BR><LI CLASS="li-itemize">Both <CODE>'-pref=val'</CODE> and <CODE>'-pref val'</CODE> are now allowed for boolean values. (The former can be used to set a preference to false.)<BR><BR><LI CLASS="li-itemize">Lot of small bugs fixed.</UL>Changes since 2.5.31:<UL CLASS="itemize"><LI CLASS="li-itemize">The <CODE>log</CODE> preference is now set to <CODE>true</CODE> by default, since the log file seems useful for most users. <LI CLASS="li-itemize">Seve
|
||
|
|
ignore = <regexp>
|
||
|
|
</PRE>in your profile (<TT>.unison/default.prf</TT>), you should put:<PRE CLASS="verbatim">
|
||
|
|
ignore = Regexp <regexp>
|
||
|
|
</PRE>Moreover, two other styles of pattern are also recognized:<PRE CLASS="verbatim">
|
||
|
|
ignore = Name <name>
|
||
|
|
</PRE>matches any path in which one component matches <CODE><name></CODE>, while<PRE CLASS="verbatim">
|
||
|
|
ignore = Path <path>
|
||
|
|
</PRE>matches exactly the path <CODE><path></CODE>.<BR><BR>Standard “globbing” conventions can be used in <CODE><name></CODE> and <CODE><path></CODE>:<UL CLASS="itemize"><LI CLASS="li-itemize">a <CODE>?</CODE> matches any single character except <CODE>/</CODE> <LI CLASS="li-itemize">a <CODE>*</CODE> matches any sequence of characters not including <CODE>/</CODE> <LI CLASS="li-itemize"><CODE>[xyz]</CODE> matches any character from the set {<TT><I>x</I></TT>, <TT><I>y</I></TT>, <TT><I>z</I></TT> } <LI CLASS="li-itemize"><CODE>{a,bb,ccc}</CODE> matches any one of <CODE>a</CODE>, <CODE>bb</CODE>, or <CODE>ccc</CODE>.</UL><BR>See the user manual for some examples.</UL>Changes since 1.146:<UL CLASS="itemize"><LI CLASS="li-itemize">Some users were reporting stack overflows when synchronizing huge directories. We found and fixed some non-tail-recursive list processing functions, which we hope will solve the problem. Please give it a try and let us know. <LI CLASS="li-itemize">Major additions to the documentation.</UL>Changes since 1.142:<UL CLASS="itemize"><LI CLASS="li-itemize">Major internal tidying and many small bugfixes. <LI CLASS="li-itemize">Major additions to the user manual. <LI CLASS="li-itemize">Unison can now be started with no arguments – it will prompt automatically for the name of a profile file containing the roots to be synchronized. This makes it possible to start the graphical UI from a desktop icon. <LI CLASS="li-itemize">Fixed a small bug where the text UI on NT was raising a 'no such signal' exception.</UL>Changes since 1.139:<UL CLASS="itemize"><LI CLASS="li-itemize">The precompiled windows binary in the last release was compiled with an old OCaml compiler, causing propagation of permissions not to work (and perhaps leading to some other strange behaviors we've heard reports about). This has been corrected. If you're using precompiled binaries on Windows, please upgrade. <LI CLASS="li-itemize">Added a <CODE>-debug</CODE> command line flag, which controls debugging of various modules. Say <CODE>-debug XXX</CODE> to enable debug tracing for module <CODE>XXX</CODE>, or <CODE>-debug all</CODE> to turn on absolutely everything. <LI CLASS="li-itemize">Fixed a small bug where the text UI on NT was raising a 'no such signal' exception.</UL>Changes since 1.111:<UL CLASS="itemize"><LI CLASS="li-itemize"><B>Incompatible change:</B> The names and formats of the preference files in the .unison directory have changed. In particular:<UL CLASS="itemize"><LI CLASS="li-itemize">the file “prefs” should be renamed to default.prf <LI CLASS="li-itemize">the contents of the file “ignore” should be merged into default.prf. Each line of the form <CODE>REGEXP</CODE> in ignore should become a line of the form <CODE>ignore = REGEXP</CODE> in default.prf.</UL><LI CLASS="li-itemize">Unison now handles permission bits and symbolic links. See the manual for details.<BR><BR><LI CLASS="li-itemize">You can now have different preference files in your .unison directory. If you start unison like this<PRE CLASS="verbatim">
|
||
|
|
unison profilename
|
||
|
|
</PRE>(i.e. with just one “anonymous” command-line argument), then the file <CODE>~/.unison/profilename.prf</CODE> will be loaded instead of <CODE>default.prf</CODE>.<BR><BR><LI CLASS="li-itemize">Some improvements to terminal handling in the text user interface<BR><BR><LI CLASS="li-itemize">Added a switch -killServer that terminates the remote server process when the unison client is shutting down, even when using sockets for communication. (By default, a remote server created using ssh/rsh is terminated automatically, while a socket server is left running.) <LI CLASS="li-itemize">When started in 'socket server' mode, unison prints 'server started' on stderr when it is ready to accept connections. (This may be useful for scripts that want to tell when a socket-mode server has finished initalization.) <LI CLASS="li-itemize">We now make a nightly mirror of our current internal development tree, in case anyone wants an up-to-the-minute version to hack around with. <LI CLASS="li-itemize">Added a file CONTRIB with some suggestions for how to help us make Unison better.</UL></div><BR><BR><HR SIZE=2><BLOCKQUOTE CLASS="quote"><EM>This document was translated from L<sup>A</sup>T<sub>E</sub>X by </EM><A HREF="http://pauillac.inria.fr/~maranget/hevea/index.html"><EM>H<FONT SIZE=2><sup>E</sup></FONT>V<FONT SIZE=2><sup>E</sup></FONT>A</EM></A><EM>.</EM></BLOCKQUOTE></BODY></HTML>
|