Two different models are commonly used for distributing data. In the first model, all clients synchronize their files with a central server. The server must be accessible by all clients at least occasionally. This model is used by subversion, CVS, and WebDAV.
The other possibility is to let all networked hosts synchronize their data between each other as peers. This is the concept followed by unison. rsync actually works in client mode, but any client can also act as a server.
subversion, CVS, and unison are also available for many other operating systems, including various Unix and Windows systems.
In subversion, CVS, WebDAV, and Unison, the data synchronization is started manually by the user. This allows fine control over the data to synchronize and easy conflict handling. However, if the synchronization intervals are too long, conflicts are more likely to occur.
Conflicts only rarely occur in subversion or CVS, even when several people work on one large program project. This is because the documents are merged on the basis of individual lines. When a conflict occurs, only one client is affected. Usually conflicts in subversion or CVS can easily be resolved.
Unison reports conflicts, allowing the affected files to be excluded from the synchronization. However, changes cannot be merged as easily as in subversion or CVS.
As opposed to subversion or CVS, where it is possible to partially accept changes in cases of conflict, WebDAV only performs a check-in when the complete modification is considered successful.
There is no conflict handling in rsync. The user is responsible for not accidentally overwriting files and manually resolving all possible conflicts. To be on safe side, a versioning system like RCS can be additionally employed.
In its standard configuration, Unison synchronizes an entire directory tree. New files appearing in the tree are automatically included in the synchronization.
In subversion or
CVS, new directories and files must be added
explicitly using the command
svn add
or
cvs add
, respectively. This
results in greater user control
over the files to synchronize. On the other hand, new files are often
overlooked, especially when the question marks in the output of
svn update
and
svn status
or cvs update
are
ignored due to the large number of files.
An additional feature of subversion or CVS is that old file versions can be reconstructed. A brief editing remark can be inserted for each change and the development of the files can easily be traced later based on the content and the remarks. This is a valuable aid for theses and program texts.
A sufficient amount of free space for all distributed data is required on the hard disks of all involved hosts. subversion and CVS require additional space for the repository database on the server. The file history is also stored on the server, requiring even more space. When files in text format are changed, only the modified lines need to be saved. Binary files require additional space amounting to the size of the file every time the file is changed.
Unison offers a graphical user interface that displays the synchronization procedures Unison wants to perform. Accept the proposal or exclude individual files from the synchronization. In text mode, interactively confirm the individual procedures.
Experienced users normally run subversion or CVS from the command line. However, graphical user interfaces are available for Linux, such as cervisia, and for other operating systems, like wincvs. Many development tools, such as kdevelop, and text editors, such as emacs, provide support for CVS or subversion. The resolution of conflicts is often much easier to perform with these front-ends.
Unison and rsync are
rather easy to use and are also suitable for
newcomers. CVS and
subversion are somewhat more difficult to
operate. Users should understand the interaction between the repository and
local data. Changes to the data should first be merged locally with the
repository. This is done with the command
cvs update
or
svn update
. Then the data must
be sent
back to the repository with the command
cvs commit
or
svn commit
. Once this procedure
has been understood,
newcomers are also able to use CVS or
subversion with ease.
During transmission, the data should ideally be protected against interception and manipulation. Unison, CVS, rsync, and subversion can easily be used via ssh (secure shell), providing security against attacks of this kind. Running CVS or Unison via rsh (remote shell) should be avoided. Accessing CVS with the pserver mechanism in insecure networks is likewise not advisable. subversion already provides the necessary security measures by running with Apache.
CVS has been used by developers for a long time to manage program projects and is extremely stable. Because the development history is saved, CVS even provides protection against certain user errors, such as unintentional deletion of a file. Despite subversion not being as common as CVS, it is already being employed in productive environments, for example, by the subversion project itself.
Unison is still relatively new, but boasts a high level of stability. However, it is more sensitive to user errors. Once the synchronization of the deletion of a file has been confirmed, there is no way to restore the file.
Table 31.1. Features of the File Synchronization Tools: -- = very poor, - = poor or not available, o = medium, + = good, ++ = excellent, x = available
unison | CVS/subv. | rsync | mailsync | |
---|---|---|---|---|
Client/Server | equal | C-S/C-S | C-S | equal |
Portability | Lin,Un*x,Win | Lin,Un*x,Win | Lin,Un*x,Win | Lin,Un*x |
Interactivity | x | x/x | x | - |
Speed | - | o/+ | + | + |
Conflicts | o | ++/++ | o | + |
File Sel. | Dir. | Sel./file, dir. | Dir. | Mailbox |
History | - | x/x | - | - |
Hard Disk Space | o | -- | o | + |
GUI | + | o/o | - | - |
Difficulty | + | o/o | + | o |
Attacks | +(ssh) | +/+(ssh) | +(ssh) | +(SSL) |
Data Loss | + | ++/++ | + | + |