Mercurial .hgignore是我处理编译时生成的数百个临时文件的唯一选择吗?

JNe*_*fer 7 version-control mercurial build-process hgignore

我一直在谷歌和SO寻找一个问过这个问题的人,但我现在完全是空的.我会提前为这个冗长的回答方式道歉.(如果我能够弄清楚如何封装问题,也许我会成功找到答案.)

如果构建/编译行为生成数百个临时文件以创建最终结果,那么Mercurial中如何管理大型项目?.hgignore唯一答案吗?

示例场景:

您有一个项目想要使用某些开源包来实现某些功能,并且需要从源代码编译.所以你去拿包裹.un-.tgz然后将其打入自己的Mercurial存储库,以便您可以开始跟踪更改.然后,您进行所有更改,然后运行构建.

您测试最终结果,对结果感到满意并准备好提交回存储库的本地克隆.因此,您hg status在提交前检查您的更改hg status结果会导致您立即开始使用会让您的母亲感到羞耻的所有单词 - 因为您现在拥有"build cruft"的屏幕和屏幕.

为了争论,说这个包是MySQL或Apache:就是这样

  1. 你无法控制,并会定期更换,
  2. 在很多地方都留下了很多东西,并且
  3. 每次从外部源获得新版本时,无法保证不会改变.

哇什么?引起这种焦虑的特定项目将由多个物理位置的多个开发人员处理,因此需要尽可能简单.如果涉及太多,他们就不会这样做,我们手上会有更大的问题.(可悲的是,一些老狗并不热衷于学习新的技巧......)

一个建议的解决方案是他们只需要在做一个make之前在本地提交所有内容,所以他们有一个"干净的平板",然后他们必须克隆到实际进行内置.这被击落为(a)太多步骤,以及(b)不想用一堆"现在建立的时间"改变集来摧毁历史.

其他人已经提出将所有这些内容都提交到Mercurial存储库中.我强烈反对,因为那时下一次这些文件将变为"已修改",因此被包含在变更集的文件列表中.

我们不可能成为遇到这个问题的唯一人.那么"正确"的解决方案是什么?我们唯一的尝试是尝试创建一个大规模智能.hginore文件?这让我感到不安,因为如果我告诉Mercurial"忽略这个目录中的所有内容我还没有告诉你",那么如果下一个应用的补丁将文件添加到该被忽略的目录中会发生什么?(Mercurial永远不会看到那个新文件,对吧?)

希望这不是一个明显答案的完全愚蠢的问题.我以前曾多次从源代码编译过东西,但从来没有需要在其上应用版本控制.另外,我们是Mercurial的新手.

Mar*_*ler 11

两种选择:

  1. 如果可以的话,最好的选择是进行树外构建.这是一个构建,您可以将对象文件放在源树之外.一些构建系统,如CMake,直接支持这一点.对于其他系统,您需要幸运,因为上游项目必须在其Makefile或类似的项目中添加对此的支持.

  2. 更通用的选择是告诉Mercurial忽略特定类型的文件,而不是整个目录.这在我的经验中很有效.

为了测试第二个选项,我想编译Apache.但是,它需要APR,所以我测试了它.在检查干净后apr-1.3.8.tar.bz2我做了./configure; make,看了一下输出hg status.前几个模板很简单:

syntax: glob

*~
*.o
*.lo
*.la
*.so
.libs/*

其余的新文件看起来像是构建过程生成的特定文件.添加它们也很容易:

% hg status --unknown --no-status >> .hgignore

这也是.hgignore因为我还没有安排添加.删除我最终得到这个.hgignore文件:

syntax: glob

*~
*.o
*.lo
*.la
*.so
.libs/*
.make.dirs
Makefile
apr-1-config
apr-config.out
apr.exp
apr.pc
build/apr_rules.mk
build/apr_rules.out
build/pkg/pkginfo
config.log
config.nice
config.status
export_vars.c
exports.c
include/apr.h
include/arch/unix/apr_private.h
libtool
test/Makefile
test/internal/Makefile

我认为这是一个非常强大的方法,可以在Mercurial或任何其他版本控制系统中解决这个问题.


Amb*_*ber 3

最好的解决方案是修复构建过程,使其以“良好”的方式运行。即允许您指定一些单独的目录来存储中间文件(然后可以通过非常简单的 .hgignore 条目完全忽略该目录)。 ..或者甚至根本不在版本控制的目录结构内。