附录

Question

让我们解释一下我的存储库的样子：

repository  
|  trunk  
|  |  folder_1  
|  |  |  file_x  
|  |  folder_2

我想在svn mv上执行file_x命令，以便将该文件从folder_1转移到folder_2。 file_x有100MB。因此，如果我使用svn mv命令，在我的存储库中将有file_x的2个引用，folder_1中的一个（已删除）和folder_2中的一个（已添加）。

我的问题是：我的存储库将使用100MB或200MB的HD？

Answer 1

不，它不会使用200MB的HD（你可以尝试一下）。即使使用svn cp subversion也不会创建新文件，但在内部使用类似unix硬链接的东西。另请参阅http://svnbook.red-bean.com/en/1.8/svn.branchmerge.using.html：

[...] Subversion继续采用这种硬链接概念。只有在需要消除不同版本对象的歧义时，它才会复制数据。 [...]

Answer 2

此举不会占用您存储库中的大量空间。

当您执行svn mv时，它只会建立从旧位置到新位置的链接。这就是Subversion在从一个位置移动到另一个位置时可以跟踪文件历史的原因。如果您使用URL进行移动，整个过程只需几分之一秒：

$ svn mv -m"Moving file_x around" \
    http://repository/trunk/folder_1/file_x \
    http://repository/trunk/folder_2

但是，我不得不问为什么file_x如此之大。我认为它是一个二进制文件。您应该尝试不在存储库中存储二进制文件，因为：

他们占用了大量空间（一个普通的Java源代码项目在源代码中占用大约200K到400K。这个100Mb文件代表200到500个Java项目！）。
他们没有很好的版本（Subversion尝试以diff格式存储东西。每个文件更改可能占用2到10K的空间。当你添加该二进制文件的第二个版本时，你将采取再增加90Mb到100Mb的空间。
历史并没有告诉你太多。（你所知道的是谁检查了这个版本的文件。不是一个版本与另一个版本之间的实际差异，以及为什么会有变化）。

最后，您最终会发现您的存储库成为您真正不关心的95％二进制文件。通常有更好的方法来存储二进制文件。例如，如果您进行Java开发，并且大多数是jar文件，则可以使用Ivy或Maven来检索它们。如果您尝试存储构建的二进制文件，则可以使用Jenkins。

附录

那么，版本化二进制文件不是一个好习惯吗？因为我是一个配置管理器，我正在管理5个项目存储库。其中一些项目与视频和图像创作有关。

是的，二进制文件占用了大量空间。版本控制中的黄金规则是从不存储二进制文件。您可以将其添加到 Big o＆＃39;在这条黄金法则之后立即出版“版本控制黄金规则”：

所有规则都可以破解。

例如，我们有一个包含大量帮助文件的Java项目。这些是由一个名为Robohelp的系统构建的，该系统采用了Microsoft Word文档并创建了一堆可用于帮助的HTML文件。即使是最初的Word文档中最微小的更改也会创建数百个名称完全不同的HTML文件。我们在Linux上构建，整个帮助系统都是在Windows上构建的（参见Microsoft Word）。

最初，该项目尝试存储生成的HTML文件，但是对于不断变换的名称，大小和其他问题，它变得很痛苦。

我想过存储Microsoft Word文件（它们本身就是二进制文件），但我无法在Linux系统上生成帮助文件。我们需要这些HTML文件进行构建。我们该怎么办？

我决定存储原始的Word文档，以及Subversion中生成的HTML帮助文件的压缩副本。这破坏了良好的版本控制管理的各种规则。但是，帮助很少改变，压缩存档意味着我们有一个必须每次更改的单个帮助文件，而不是添加和删除数百个。整个拉链大约15K。它起作用了，我们根本无法找到更好的解决方案。

从未参与过视频项目，我将猜测。这意味着我只是从我的解剖结构中汲取了一些东西，而这些东西并没有得到太多的阳光照射。

您的视频项目如何运作？是否有一些构建语言可以获取所有视频剪辑，声音资源等，并将它们组合在一起。如果是这样，很明显最终的项目不应该被存储，而是将你的剪辑存储在某个地方，并构建你的项目。

我感觉项目保存在一个庞大的大型文件中，其中包含单独存储所需资源的所有链接。各种各样的零碎都会改变吗？我可以想象编辑声音片段以提高清晰度，添加效果等。您可能希望保留该历史记录。或者，也许一个项目使用该剪辑的旧版本，而另一个项目使用较新版本。也许这些剪辑必须受版本控制。

也许整个项目及其所有资源都保存在一个项目文件中。我可以从库中导入剪辑，但实际项目是你之前谈过的100Mb file_x。

源代码管理不只是保留文件历史记录，而是将文件历史记录保存在数百个，可能是数千个文件同步中。如果您的项目依赖于2000个文件，如果您不知道这些文件的哪些版本在一起，那么它并没有多大帮助。有那个和分支，允许多个开发流。如果您不处理整个项目或多个开发流中的文件同步版本，则可能不需要真正的源代码管理系统。

NetApps 是一个高可用性系统，允许快照并恢复到旧版本的文件。它速度快，坚固耐用。这就是它在许多数据商店中流行的原因。我们有一个存储数据库的地方。我们可以在数据库上运行测试，然后还原更改并运行测试。该90Gb数据库的整个修订过程耗时4 1/2秒。

而且，NetApps可以低至几百万美元！另外，如果你问得好，他们会穿上一件T恤。（提到我的名字，也许我也会得到一件T恤！）。不是典型视频工作室的预算？

Dropbox 也会执行文件历史记录快照和跟踪。您甚至可以恢复以前删除的文件。每月10美元，你可以获得1TB的存储空间和一个跟踪所有文件变化（包括添加和删除）一整年的系统。但是，没有T恤。

Google ， Microsoft ，亚马逊，很快 Apple 也会以类似价格提供类似服务。每个人都有自己的优势和工作方式。大多数允许试用或免费服务，你可以尝试只有几十GB的存储空间。

很难知道什么最适合你。也许Subversion是最好的方法，在经过一年的多个项目和更改后，您只需要处理一个非常大的Subversion存储库（大小为100千兆字节）。其他一些版本控制系统能够删除过时的文件和版本以节省空间。其中一个可能会更好。

考虑您的需求，并找出最适合您的方法。

svn存储库如何使用HD空间？

2 个答案:

附录