在分发数据时，常用的有两个模型。在第一个模型中，所有客户机都通过中央服务器来同步文件。所有客户机都应能够访问该服务器（至少能偶尔为之）。subversion、CVS 和 WebDAV 使用的都是这个模型。

另一个模型是让所有联网主机作为同级相互同步数据。unison 遵照的就是这种概念。rsync 实际是以客户机方式工作，但任一台客户机又可以充当服务器。

subversion、CVS 和 unison 还适用于其他很多操作系统，包括各种 Unix 和 Windows 系统。

在 subversion、CVS、WebDAV 和 Unison 中，数据同步是由用户手工启动的。这样可以有效控制要同步的数据并易于解决冲突。不过，如果同步间隔过长，就容易发生冲突。

在 subversion 或 CVS 中很少发生冲突，即便是多人同时在一个大型程序项目上协作时也不例外。这是因为合并文档时基于的是单个行。发生冲突时，只有一个客户机会受影响。通常很容易解决 subversion 或 CVS 中发生的冲突。

Unison 可以报告冲突，允许从同步中排除受影响的文件。不过，合并更改时并不像在 subversion 或 CVS 中那样容易。

不同于 subversion 或 CVS（这两个程序允许在发生冲突时部分接受更改），WebDAV 只有在成功进行完整修改后才执行签入。

rsync 中不提供冲突解决功能。用户自己要避免意外覆盖文件，并手工解决所有可能的冲突。为安全起见，还可以使用 RCS 之类的版本控制系统。

按照 Unison 的标准配置，它会同步整个目录树。目录树中新出现的文件将被自动纳入同步。

在 subversion 或 CVS 中，必须分别使用命令 svn add 或 cvs add 明确添加新目录和文件。这样用户可以更有效地控制要同步的文件。但另一方面，这样也容易遗漏新文件，特别是在有大量文件时，很容易忽略 svn update 和 svn status 或 cvs update 输出中的问号。

subversion 或 CVS 的另一个功能是能够重建旧文件版本。每次一有更改都可以插入一个简短的编辑注释，以后根据文件内容和这些注释就很容易跟踪文件的变化。这对论文和程序文本大有帮助。

所有相关主机的硬盘上都要有足够的可用于所有分发数据的空间。subversion 和 CVS 还要求服务器为储存库准备额外的空间。文件历史记录也储存在服务器上，这进一步增加了空间要求。更改文本格式的文件时，只需保存修改的那些行。而二进制文件则要求在每次更改文件时都要有与文件大小相同的额外空间。

Unison 提供图形用户界面，显示 Unison 要执行的同步过程。可以接受建议或从同步中排除单个文件。在文本方式中，交互确认各个过程。

有经验的用户通常从命令行运行 subversion 或 CVS。不过，图形用户界面也适用于 Linux（如 cervisia）以及其他操作系统（如 wincvs）。许多开发工具（如 kdevelop）及文本编辑器（如 emacs）都提供针对 CVS 或 subversion 的支持。在这些前端上解决冲突往往较为容易。

Unison 和 rsync 较便于使用，因此适合新手使用。CVS 和 subversion 相对而言较难操作。用户应该了解储存库和本地数据之间如何交互。对数据的更改首先要在本地与储存库合并。使用命令 cvs update 或 svn update 可完成上述操作。然后必须使用命令 cvs commit 或 svn commit 将数据发回储存库。一旦了解了此过程，新手也就能毫不费力地使用 CVS 或 subversion 了。

在传送数据的过程中，最好防止数据被拦截或操纵。Unison、CVS、rsync 和 subversion 可以方便地通过 ssh（安全 shell）使用，从而防止遭受此类攻击。应避免通过 rsh（远程 shell）运行 CVS 或 Unison。同时也不建议在不安全的网络中使用 pserver 机制访问 CVS。subversion 若与 Apache 同时运行就已经提供了必要的安全措施。

开发人员使用 CVS 来管理程序项目已有很长时间，所以该程序极为稳定。由于能够保存开发历史记录，CVS 甚至能够预防某些用户错误，如意外删除文件。尽管 subversion 不如 CVS 常用，但它已运用到生产环境中，例如供 subversion 项目本身使用。

Unison 仍然是个较新的程序，但它的稳定性极高。不过，它对用户错误较为敏感。一旦确认对已删除的文件进行同步，就无法再恢复该文件。