对于二进制文件，我应该使用 bfiles 还是 bigfiles？
有一些善变的扩展可用于处理大型二进制文件。
我想使用最有可能是官方的（即与 Mercurial 一起分发）。
Kiln 2.0 使用 Bfiles 的分支作为其二进制文件。这是否使它更有可能成为正式的？
哪个是处理二进制文件的首选（半官方）扩展名？
There are a few mercurial extensions for dealing with large binary files.
I'd like to use the one that is most likely to be official (ie distributed with mercurial).
Kiln 2.0 uses a fork of Bfiles for its binary files. Does that make it more likely to become official?
Which is the preferred (semi-official) extension for handling binary files?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Mercurial 似乎计划在 11 月 2.0 版本中纳入“largefiles”扩展。< /strike> Mercurial 在 2.0 版本中合并了“largefiles”扩展< /a>.此扩展是“kbfiles”（来自 Kiln）的后代，而“kbfiles”又是 bfiles 扩展< /a>.它使大文件支持比 bfiles 更加集成到 Mercurial 命令中，并且支持推送到 http(s) url，而我相信 bfiles 不支持。
It appears that Mercurial is planning to incorporate the 'largefiles' extension for the November 2.0 release.Mercurial incorporated the 'largefiles' extension in the 2.0 release. This extension is a descendent of 'kbfiles' (from Kiln), which is in turn a descendent of the bfiles extension.It makes largefile support much more integrated into the Mercurial commands than bfiles did, and supports pushing to http(s) urls which I believe bfiles did not.
现在说还为时过早。现在开始谈论在 Mercurial 中包含任何这些扩展还为时过早。恕我直言，它们都应该被视为实验性的。
（我是其中一个扩展 (bfiles) 的作者，因此这是您可能得到的最权威的答案。如果有人建议今天使用 Mercurial 发布这些扩展中的任何一个，包括我的，我会极力反对。）
此外，游戏开发和选择哪个扩展之间没有逻辑联系。无论您是跟踪电影、游戏数据、jar 文件、医学成像数据还是其他什么，都没关系：大多数源代码控制系统都不太擅长处理它，而且还没有明确的答案，哪一个是正确的方法使用 Mercurial 来完成此操作。
恕我直言，stackoverflow 确实不适合进行此类讨论； Mercurial-devel 列表是。
It's too early to tell. And it is way too early to start talking about including any of these extensions with Mercurial. IMHO they should all be considered experimental.
(I'm the author of one of those extensions (bfiles), so this is as authoritative an answer as you are likely to get. If someone proposed shipping any one of these extensions with Mercurial today, including mine, I would be strenuously opposed.)
Also, there is no logical link between game development and which extension to choose. It doesn't matter if you're tracking movies, game data, jar files, medical imaging data, or what: most source-control systems are not very good at handling it, and there is no clear answer yet which is the right way to do it with Mercurial.
IMHO stackoverflow is really not the right place for this sort of discussion; the mercurial-devel list is.
似乎使用 Mercurial 的游戏开发者推荐使用 BigFiles ，所以也许你应该接受它。但是，如果您想知道即将推出的 Mercurial 版本中包含哪一个，您应该询问或阅读开发人员的邮件列表。
It seems that BigFiles is recommanded by game developpers using Mercurial, so maybe you should go with it. However if you want to know wich one is worked to be included in a coming version of mercurial, you should ask in or read the developers' mailing list.
呃... Nexus。或任何其他工件存储库（或任何其他备份系统（如果您只需要最新版本）。
因为没有任何二进制文件（尤其是大文件）真正属于您想要比较或合并的 VCS。
当然，您可以使用 VCS，并且有 实际上是很好的论据，但 VCS 的核心根本就不是为此而设计的。
Errr... Nexus. Or any other artifact repositories (or any other backup systems if you only need the latest version).
Because no binary file (especially large one) really belong to a VCS where you would want to diff or merge.
Sure, you could use a VCS, and there are actually good arguments for it, but a VCS is simply not designed for that at its core.