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 among 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 unison 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.

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 or 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. As the development history is saved, CVS even provides protection against certain user errors, such as the 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.