logo标签列表

如何在分布式版本控制系统中适当地管理大型艺术资源？

version-controldvcsasset-management
51
有没有一种好的方法来处理大型资产（如1000多个图片、Flash影片等），并使用DVCS工具（例如hg和git）进行管理？就我看来，克隆填满4 GB资产的存储库似乎是不必要的开销，因为您将检出文件。如果您将源代码与资产文件混合在一起，这似乎相当麻烦。

在Web开发环境中，有人有任何想法或经验吗？

git似乎不能像您希望的那样扩展。http://stevehanov.ca/blog/index.php?id=50 - Spoike
如果你只是想缩小你的代码库，那么这些链接可能会对你有帮助：如何缩小 .git 文件夹。我在那里也有一个答案：点击这里。另外，如果数据重复，git gc 可能会有很大帮助：Git 在文件之间去重吗？。 - Gabriel Staples
5个回答
40
这是我对此问题的一些想法。最终，您可能需要尽可能将资产和代码分开。我可以想到几种可能的策略：
分布式，两个仓库
一个仓库中有资产，另一个仓库中有代码。
优点：
- 在 Web 开发环境中，如果您不直接使用图形文件，则无需克隆庞大的资产库。这是可能的，如果您有一个处理资产与动态内容（PHP、ASP.NET、RoR 等）分离并与资产库同步的 Web 服务器。 缺点： - DVCS 工具不跟踪其他存储库，因此没有直接的 BOM（物料清单）支持，即没有明确的方法告诉何时两个存储库同步。（我猜这就是 git-submodule 或 repo 的用途）。 - 示例：艺术家在一个存储库中添加了新图片，程序员添加了使用该图片的函数，但是当有人必须回溯版本时，他们被迫自己跟踪这些更改。 - 资产库开销，即使它只影响那些使用它的人。
分布式，一个仓库
资产和代码驻留在同一个仓库中，但它们位于两个单独的目录中。
优点：
  • 代码和资源的版本控制是交织在一起的，因此BOM非常实用。可以轻松进行回溯。

缺点

  • 由于分布式版本控制工具会跟踪整个项目结构，因此通常无法仅检出一个目录。
  • 你仍然需要处理仓库开销问题。而且，你需要检出资产以及代码。

以上两种策略仍然存在一个缺点：由于需要克隆大型资产仓库，所以存在较大的开销。解决此问题的一个方法是第一种策略的变体: 两个仓库; 将代码存储在分布式VCS存储库中，将资源存储在集中式VCS存储库中（如SVN，Alienbrain等）。

考虑到大多数图形设计师使用二进制文件工作，通常没有必要进行分支，除非真正需要（需要大量资源的新功能直到更晚才需要）。缺点是你需要找到一种备份中央仓库的方式。因此，有第三种策略:

仓库外的资源（或者在CMS中的资源）

像往常一样在存储库中保存代码，而不将资产保存在存储库中。应将资产放入某种内容/媒体/资产管理系统中，或者至少放在一个定期备份的文件夹中。这假设几乎不需要使用图形进行版本回溯。如果需要回溯，则图形更改可以忽略不计。

优点

  • 不会使代码仓库臃肿（对于频繁进行文件检查的git非常有帮助）
  • 使资产的处理更加灵活，例如将资产部署到专门用于资产的服务器上
  • 如果在具有API的CMS上，则在代码中相对容易处理资产

缺点

  • 不支持BOM
  • 没有易于进行广泛版本回溯的支持，这取决于您的资产备份策略
增加了第三个选项。当我最初写下这个答案后，经过几年的CMS系统工作后，我发现这种情况比我想象的更为普遍。 - Spoike
3

想法，无经验：我确实会将代码与数据分离。假设有一组属于应用程序的图像，则只需将其保存在集中式服务器上。然后，在代码中，我会通过显式编码安排应用程序可以集成本地或远程资产。贡献者可以首先将新图像放入其本地存储中，然后在需要和获得批准时，通过某种（显式）上传过程将其集成到中央存储库中。

2
我也曾经为此苦恼。正如你所说，版本控制大量资产可能会非常麻烦。
对于需要外部参与的项目，我发现Mercurial是一个可行的解决方案，但并不是最好的选择。对于大文件，它会占用大量磁盘空间，并且根据情况可能会相当缓慢。
对于我的内部设计工作，我更喜欢使用简单的同步工具（rsync、synctoy等）来保持服务器/机器之间的目录更新，然后手动进行版本控制。我发现除了主要修订之外，很少需要进行版本控制。
1
git lfs 也可以是一种非常糟糕的痛苦。 - Gabriel Staples
0

游戏开发行业中一个相当受欢迎的选项（带有庞大的代码库）是使用 Plastic SCM。

他们提供将二进制大对象存储在文件系统而非数据库中的选项。

https://www.plasticscm.com

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接