如何在 DVCS 中适当管理大型艺术资产？
是否有任何好的方法可以使用诸如hg 和 git。在我看来，克隆充满 4 GB 资源的存储库似乎是不必要的开销，因为您将检查文件。如果您将源代码与资产文件混合在一起，这似乎相当麻烦。
有谁在网络开发环境中对此有任何想法或经验吗？
Is there any good way to handle large assets (i.e. 1000's of images, flash movies etc.) with a DVCS tool such as hg and git. As I see it, to clone repositories that are filled with 4 GB assets seems like an unnecessary overhead as you will be checking out the files. It seems rather cumbersome if you have source code mixed together with asset files.
Does anyone have any thoughts or experience in doing this in a web development context?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这些是我对这个主题的一些想法。最后，您可能需要将资产和代码尽可能分开。我可以想到几种可能的策略：
分布式、两个存储库
资产在一个存储库中，代码在另一个存储库中。
优点
缺点
DVCS 工具不会跟踪除自己之外的其他存储库，因此没有任何直接的 BOM（物料清单）支持，即没有明确的方法来判断两个存储库何时同步。 （我想这就是 git-submodule 或 repo 适用于）。
示例：艺术家在一个存储库中添加一张新图片，程序员添加使用该图片的功能，但是当有人必须回溯版本时，他们被迫以某种方式自己跟踪这些更改。
资产存储库开销，即使它只影响那些使用它的人。
分布式、单一存储库
资产和代码驻留在同一存储库中，但位于两个单独的目录中。
优点
缺点
上面列出的两种策略仍然存在开销较大的缺点，因为您需要克隆大型资产存储库。这个问题的一个解决方案是上面第一个策略的变体，两个存储库；将代码保存在分布式 VCS 存储库中，将资产保存在集中式 VCS 存储库中（例如 SVN、Alienbrain 等）。
考虑到大多数图形设计师如何使用二进制文件，除非确实有必要，否则通常不需要分支（新功能需要大量资源，直到很久以后才需要）。缺点是您需要找到一种方法来备份中央存储库。因此，第三种策略是：
存储库外资产（或 CMS 中的资产）
代码照常存储在存储库中，而资产不在存储库中。资产应该放在某种内容/媒体/资产管理系统中，或者至少放在定期备份的文件夹中。这假设几乎不需要回溯带图形的版本。如果需要回溯，则图形变化可以忽略不计。
优点
缺点
These are some thoughts I've had on this matter of subject. In the end you may need to keep assets and code as separate as possible. I can think of several possible strategies:
Distributed, Two Repositories
Assets in one repo and code in the other.
Advantages
Disadvantages
DVCS tools don't keep track of other repositories than their own so there isn't any direct BOM (Bill of Materials) support, i.e. there is no clear cut way to tell when both repositories are in sync. (I guess this is what git-submodule or repo is for).
Example: artist adds a new picture in one repository and programmer adds function to use the picture, however when someone has to backtrack versions they are forced to somehow keep track of these changes on their own.
Asset repository overhead even though it only affects those who do use it.
Distributed, One Repository
Assets and code reside in the same repository but they are in two separate directories.
Advantages
Disadvantages
Both strategies listed above still have the disadvantage of having a large overhead since you need to clone the large asset repository. One solution to this problem is a variant of the first strategy above, two repositories; keep the code in the distributed VCS repo and the assets in a centralized VCS repo (such as SVN, Alienbrain, etc).
Considering how most graphic designers work with binary files there is usually no need to branch unless it is really necessary (new features requiring lots of assets that isn't needed until much later). The disadvantage is that you will need to find a way to back up the central repository. Hence a third strategy:
Off-Repository Assets (or Assets in CMS instead)
Code in repository as usual and assets are not in repository. Assets should be put in some kind of content/media/asset management system instead or at least is on a folder that is regularly backed up. This assumes that there is very little need to back-track versions with graphics. If there is a need for back-tracking then graphic changes are negligible.
Advantages
Disadvantages
想法，没有经验：我确实会将代码与数据分开。假设有一组属于该应用程序的图像，我会将其保留在中央服务器上。然后，在代码中，我将安排（通过显式编码）应用程序可以集成本地或远程资产。然后，贡献者可以首先将新图像放入本地存储中，并在需要并获得批准时将其与某种（显式）上传程序集成到中央存储中。
Thoughts, no experience: I would indeed seperate code from data. Assuming that there is a set of images that belongs to the application, I would just keep that on a centralized server. In the code, I would then arrange (through explicit coding) that the application can integrate both local or remote assets. People contributing can then put new images in their local store at first, integrating it with some kind of (explicit) upload procedure into the central store when required and approved.
我自己也曾为此苦苦挣扎。正如您所说，对 GB 的资产进行版本控制可能会非常痛苦。
对于需要外部参与的项目，我发现 Mercurial 是一种可行的解决方案，但不是一个很好的解决方案。它会占用大文件的磁盘空间，并且根据具体情况可能会相当慢。
对于我的内部设计工作，我更喜欢使用简单的同步工具（rsync、synctoy 等）来保持服务器/计算机之间的目录最新，然后手动进行版本控制。我发现除了重大修订之外，我很少需要对任何内容进行版本控制。
I've struggled with this myself. As you said, versioning GBs of assets can be a huge pain.
For projects that require external participation I've found Mercurial to be a working solution, but not a great one. It eats up disks space for large files and can be fairly slow depending on the circumstances.
For my in-house design work I prefer to use simple syncing tools (rsync, synctoy, whatever else) to keep directories up-to-date between servers/machines and then do version control manually. I find I rarely need to version-control for anything beyond major revisions.
也许在这种情况下应该提到 GIT LFS （另请参阅 Atlassian 的 git lfs 教程 ）
Maybe GIT LFS should be mentioned in this context (see also Atlassian's git lfs tutorial)
游戏开发行业（拥有庞大的存储库）中一种相当流行的选择是使用 Plastic SCM。
他们可以选择将 blob 存储在文件系统而不是数据库中。
https://www. Plasticscm.com
One fairly popular option within the game development industry (with huge repositories) is to use Plastic SCM.
They have options to store blobs in the file system instead of the database.
https://www.plasticscm.com