我有很多“二进制媒体”，我将其抽象为“MP3”。我还有几台电脑，我想把整个库都放在上面 - 台式机、媒体盒、笔记本电脑等。简而言之，如果能够将这些机器同步，让它们都拥有相同的文件堆栈，那就太好了。
版本控制系统（与 rsync/robocopy lashup 相反）从粗略意义上讲似乎是可行的方法。首先，涉及多个操作系统（Windows、Mac、Linux 版本）。其次，如果在更新 ID3 标签等时，系统可以只更新文件增量，而不是重新复制整个文件，那就太好了。（最后，能够通过互联网而不是局域网更新库将非常酷。）
但是传统的 CVS/SVN 系统有一个明显的缺点，就是需要完整的存储库才能工作，而且我真的不想将 60gb+ MP3 文件夹的两个副本放在某台机器上，而且传统上也不能很好地处理二进制增量。
因此，分布式版本控制从这一点上听起来相当不错。 Mercurial，git， 和市场纸面上看起来都不错，但我对它们都没有任何经验。有人尝试用它们中的任何一个设置“仅二进制”DVCS 吗？有什么建议吗？有什么陷阱吗？
答案1
但是传统的 CVS/SVN 系统有一个明显的缺点，就是需要完整的存储库才能工作，而且我真的不想将 60gb+ MP3 文件夹的两个副本放在某台机器上，而且传统上也不能很好地处理二进制增量。
使用 CVS/SVN 你有一存储库和多个工作副本。因此，存储库包含每个文件一次以及每个文件的完整历史记录。工作副本包含每个文件一次以及每个文件的一些附加数据（通常约为文件的大小）。
粗略地讲：我们假设我们的修订控制系统无法有效地存储二进制文件的差异（并非事实，但为了简单起见）。您的收藏是 60 GB 的 MP3 文件。如果平均每个文件有 10 个修订版本，并且我们忽略压缩（因为 MP3 压缩效果很差），您的存储库将约为 600 GB，而您的工作副本约为 120 GB。
因此，分布式版本控制从这一点上听起来相当不错。
在分布式系统中，每个工作副本本质上都是一个存储库，这意味着每个工作副本都包含每个文件和历史记录。
与上述假设相同，每一个副本大约有 600 GB。
底线是，分布式系统比集中式系统需要更多的空间。
编辑：
即使您的问题更多是关于大量二进制文件而不是版本控制中的大型二进制文件，以下帖子也可能很有趣：重新审视大型二进制文件问题。
答案2
这实际上不是你问题的答案，但我已经开始使用DropBox目的相同。它是跨平台的，如果您不介意多付一点钱，您可以获得 100GB 的帐户。它还存储文件的修订版本，与源代码控制非常相似。
答案3
尝试将版本控制系统强行纳入文件同步系统的问题是，您最终会浪费大量磁盘空间来将所有旧版本历史数据保存在存储库中。
就我个人而言，对于我的大型二进制媒体收藏，我并不关心能否恢复对任何给定文件的更改。我只关心收藏是否在我的系统之间同步。目前有许多文件同步解决方案，但它们都有各自的优缺点。有些声称它们是跨平台的，但这只意味着 Win/Mac。其他的确实是跨平台的，但没有足够大的文件大小/数量限制，无法用于大型收藏。有些提供对文件的 Web 访问，但也受到文件大小/数量限制的影响。如果您有大量文件，那么任何在第三方服务器上保存文件副本的解决方案都不可避免地会花费您的钱。
答案4
Windows Vista 和 Windows 7 提供卷影复制/以前的版本。它的功能肯定不如真正的源代码控制提供程序丰富，但确实能给你带来一些好处。正如其他人所说，保存多个修订版本所需的存储空间可能相当大——具体取决于文件的大小。
免费和流行的 SCM 在这项任务上都表现一般。例如，SVN 可以很好地工作，但存储库会快速增长，并且本地 .svn 文件夹也会相当大。
当所有事情都完成后，你可能要考虑在对你的收藏进行任何大的更改之前，简单地将整个文件复制到一个安全的地方；当你在日常生活中实际使用 MP3 时，没有太多的理由更改文件，而且拥有一个监视很少更改的大型二进制文件的修订系统的费用似乎很难证明是合理的……但如果你决心这样做，那么 SVN 至少会进行二进制差异比较，CVS 会进行完整复制（大得多）