使用源代码控制来同步重介质文件夹的开销

Question

我在考虑使用现有的远程连接的svn存储库基础架构作为同步媒体文件夹的方法。

媒体我的意思是大约1Tb的视频内容。

使用SVN做它有什么不利之处吗？

传输协议是否有效传输大文件？

存储空间是否有开销？

由于

Answer 1

我强烈建议您不要使用Subversion（或任何为源代码设计的版本控制系统）来执行此操作。 Subversion可以处理二进制文件，但是你没有得到合并，差异等功能，这是使用像Subversion这样的东西的主要原因。从技术上讲，它很可能会起作用;但是，有更好的工具可以完成这项工作。

如果你正在做的只是同步文件夹，请尝试rsync。

如果需要，AlienBrain之类的内容可以为您提供版本控制功能。

Answer 2

正如我在评论中所说，SVN是关于源控制的。 它不是一个合作工具，即使您也可以将它用于此目的。

也就是说，SVN适用于二进制文件（如媒体文件）。 当然，你不能在二进制文件上获得差异，但它对存储来说非常好。

正如SVN手册所述：

  

请注意，文件是否为二进制文件不会影响金额   存储库空间用于存储对该文件的更改，也不存储   影响客户端和服务器之间的流量。用于存储   和传输目的，Subversion使用一种有效的diffing方法   同样适用于二进制和文本文件;这与完全无关   'svn diff'命令使用的diffing方法。

但请记住，如果你只需要同步，你可能有比SVN更好的选择。 因此，在决定使用SVN之前，请尝试查看其他解决方案，例如rsync。

Answer 3

subversion客户端存在大量开销。

对大型媒体文件使用subversion的主要问题是标准客户端将文件的“原始”副本存储在本地工作区中，从而有效地将库的已检出副本的大小加倍。这是对设计器部件的有意识选择，它有利于源控制的标准subversion用例，但对于大型二进制文件不是最佳选择。有一次，有没有这个问题的备用客户 - 我最近没看过。

在subversion服务器端经常存在开销/效率低下。

第二个问题是，如果存储压缩的二进制文件，文件内容的微小变化将产生完全不同的压缩结果，渲染颠覆增量存储策略无用。请注意，MP3和许多视频格式都是压缩，但压缩发生在块上。因此，当您看到此问题在行动时 - 一个小的更改将影响整个块 - 它不一定会影响整个文件。

SCM工具中的假设

我不同意SCM工具对于你正在尝试做的事情来说一定是糟糕的选择，但是大多数工具并没有考虑到这一点，因此存在问题。对于我的媒体要求，工作流程比SCM工具更接近于rsync，unison等同步工具。但是，SCM中的一些基本假设对大文件不起作用。

如果您的工作流程会对文件进行大量更改，那么您可能会非常积极地清除旧版本的数据。大多数SCM工具的设计理念是旧数据非常重要，并且旧数据的存储相对便宜（文件很小并且压缩良好）。因此，虽然我所熟悉的所有SCM工具（很多！）都有办法做到这一点，但通常（并且有意）不容易做到。

结论

总之，您可以选择不愉快的选择。像颠覆这样的SCM工具有关于存储空间和保留的假设，可以快速满足存储要求，但文件同步工具通常不支持大多数人在其媒体库中真正喜欢的工作流程。

何时使用Subversion

如果您不介意将客户端设备上使用的磁盘空间加倍，并使服务器额外增加2倍的磁盘空间（扩展空间），并且您希望很少更改文件（例如，只需更改MP3标签或一些这样的）然后颠覆可能适合你。

如果您正在推动存储空间的限制（SSD？），那么“开箱即用”的颠覆可能不是您想要的，尽管您仍然可以将其用作解决方案的一部分。