如何在DVCS中适当地管理大型艺术品资产？

Question

是否有处理大型资产的好方法(如1000多幅图像、闪存电影等)使用DVCS工具，如hg和git。在我看来，克隆包含4GB资产的存储库似乎是不必要的开销，因为您将检查这些文件。如果将源代码与资产文件混为一谈，这似乎相当麻烦。

有没有人有在web开发环境中这样做的想法或经验？

Answer 1

这些是我在这个问题上的一些想法。最后，您可能需要尽可能地保持资产和代码的独立性。我可以想出几种可能的策略：

分布式，两个存储库

一个回购中的资产和另一个回购中的代码。

优势

• 在web开发环境中，如果不直接处理图形文件，就不需要克隆巨大的资产存储库。如果您有一个web服务器来处理与动态内容分离的资产(PHP、ASP.NET、RoR等)，这是可能的。并与资产回购同步。

缺点

• DVCS工具不跟踪其他存储库，因此没有任何直接的BOM (物料清单)支持，也就是说，没有明确的方式来判断两个存储库何时同步。(我猜这就是git-子模或存储库的用途)。 例如:艺术家在一个存储库中添加了一幅新的图片，程序员添加了函数来使用该图片，但是当某个人不得不回溯版本时，他们不得不自己跟踪这些更改。
• 资产存储库开销，即使它只影响使用它的人。

分发，一个储存库

资产和代码驻留在同一个存储库中，但它们位于两个不同的目录中。

优势

• 代码和资产的版本控制是交织在一起的，因此BOM是实用的。回溯是可能的，没有太多的麻烦。

缺点

• 由于分布式版本控制工具跟踪整个项目结构，所以通常无法只签出一个目录。
• 存储库开销仍然存在问题。更重要的是，您需要检查资产以及代码。

上面列出的两种策略仍然存在开销大的缺点，因为您需要克隆大型资产存储库。解决此问题的一个解决方案是上述第一个策略的一个变体，即两个存储库；将代码保存在分布式VCS中，将资产保存在集中式VCS中(例如SVN、Alienbrain等)。

考虑到大多数图形设计人员如何处理二进制文件，通常不需要分支，除非它是真正必要的(新特性需要大量的资产，直到很久以后才需要)。缺点是您需要找到一种备份中央存储库的方法。因此，第三项战略：

非仓库资产(或改为CMS中的资产)

与往常一样，存储库中的代码和资产不在存储库中。资产应该放在某种内容/媒体/资产管理系统中，或者至少放在定期备份的文件夹中。这假设很少需要用图形来追溯版本。如果需要回溯，那么图形变化是可以忽略不计的。

优势

• 不会使代码库臃肿(例如，git经常进行文件检查)
• 允许灵活处理资产，例如将资产部署到专用于仅用于资产的服务器上
• 如果在带有API的CMS上，资产应该在代码中相对容易处理。

缺点

• 没有BOM支持
• 没有简单的、广泛的版本回溯支持，这取决于您的资产的备份策略。

Answer 2

思想，没有经验:我确实会把代码和数据分开。假设有一组属于应用程序的映像，我将把它保存在一个集中的服务器上。在代码中，我会安排(通过显式编码)应用程序可以集成本地或远程资产。然后，投稿人员首先可以将新的图片放在他们的本地商店中，并在需要和批准时将其与某种(显式)上传过程集成到中央商店中。

Answer 3

我自己也和这事做过斗争。正如您所说，对资产的GBs进行版本控制可能会带来巨大的痛苦。

对于需要外部参与的项目，我发现Mercurial是一个可行的解决方案，但不是一个很好的解决方案。它占用了大文件的磁盘空间，而且可能会很慢，这取决于环境。

在我的内部设计工作中，我更喜欢使用简单的同步工具(rsync、synctoy等)来保持目录在服务器/机器之间的最新更新，然后手动进行版本控制。我发现除了主要的修订之外，我很少需要版本控制。