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

另一个模型是让所有联网主机作为同级相互同步数据。 rsync 实际在客户机模式下工作，但任何客户机都可用作服务器。

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

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

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

rsync 中不提供冲突解决功能。 用户自己要避免意外覆盖文件，并手动解决所有可能的冲突。 为确保安全，还可以额外使用分版本系统。

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

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

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

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

rsync 相当容易使用，还适合初学者。CVS 某种程度上较难操作。用户应该了解安装源和本地数据之间如何交互。 对数据的更改首先要在本地与安装源合并。 使用命令 cvs update 可完成上述操作。 然后必须使用命令 cvs commit 将更改发回安装源。 一旦了解了此过程，新手也就能毫不费力地使用 CVS 了。

在传送数据的过程中，最好防止数据被拦截或操纵。 CVS 和 rsync 可以方便地通过 ssh（安全 shell）使用，从而防止遭受此类攻击。 应避免通过 rsh（远程 shell）运行 CVS。 也不建议在不安全的网络中使用 pserver 机制访问 CVS。

开发人员使用 CVS 来管理程序项目已有很长时间，所以该程序极为稳定。 由于能够保存开发历史记录，CVS 甚至能够预防某些用户错误，如意外删除文件。