Mercurial - 如何停止跟踪修改的文件但将第一个版本保留在存储库中
我用我的源代码树创建了 hg 存储库。我想将一些文件的第一个版本(例如 Makefile
)保留在存储库中,然后即使我修改了它, hg 也看不到它被修改。
最初的问题是 ./configure
通常会修改 Makefile
但我不希望将构建文件提交到存储库中。因此,我只想在存储库中保留第一个版本的configure和Makefile
,以便克隆我的存储库的每个人都可以自己运行./configure
,而不会打扰
我尝试过的 存储库hgremove
或 hgforget
但这些将停止跟踪,并删除存储库的下一个版本中的文件。
.hgignore
也不做这些事情。
每次运行 ./configure
或 make 时,我都会想到 hg revert
,但这不是有效的方法。 还有更好的方法吗?
I create the hg repository with my source tree. I want to keep the first version of some files such as Makefile
in the repository and then hg don't see it modified even through I modified it.
Original problem is that ./configure
usually modifies the Makefile
but I don't want the build files to committed in the repository. So I want to keep only first version of configure and Makefile
in the repository so that everybody who clone my repository can run ./configure
by themself and not bother the repository
I tried hg remove
or hg forget
but those are stop tracking and also delete the files in the next revision of reporitory.
.hgignore
doesn't do the things too.
I think of hg revert
everytimes I run ./configure
or make but it's not efficient way.
Are there any better ways?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
根本不跟踪
configure
脚本通常是一种很好的形式。这有一些原因:它太大了。我见过一些代码库,其中配置脚本和辅助宏库的大小是正在编译的实际代码的十倍以上。
当其他开发人员对configure.in(.ac)进行更改时,他们将需要提交新的
configure
脚本。如果三个人这样做,Mercurial 很可能需要其中至少一个人来手动解决configure
本身的合并冲突。请记住,configure
是机器生成的,尝试读取它(更不用说解决合并冲突)可能会让您的眼睛流血。一般来说,您将通过两种方法以源代码形式提供程序:
下载发布存档(例如 foo-1.2.3-rc2.zip),其中可以包含配置脚本。
使用 Mercurial 直接下载存储库。如果他们想要使用它,则需要安装 autoconf。
在我的存储库的根目录中,我通常包含一个名为
autogen.sh
的文件,该文件运行所需的所有步骤(aclocal
、autoconf
、. ..),如果用户需要安装某些东西,它还会提醒用户。即找不到工具 aclocal,请安装 autoconf 包。
最好使用
autogen.sh
方法。这意味着仅跟踪configure.in(或configure.ac)和关联的Makefile(来自Makefile.in)。让每个构建配置自己的,并提供一个distclean
目标来删除configure
生成的所有文件。最后,提供一个maintainer-clean
目标来删除配置套件本身生成的任何内容,例如configure
。这应该有助于使夜间构建变得容易。
Its usually good form to not track the
configure
script at all. There are some reasons for this:Its huge. I've seen code bases where the configure script and helper macro libraries were more than ten times the size of the actual code being compiled.
When other developers make changes to configure.in(.ac), they are going to need to commit a new
configure
script. If three people do that, there's a good chance that Mercurial will require at least one of them to manually resolve a merge conflict inconfigure
itself. Keep in mind,configure
is machine generated, attempting to read it (much less resolve merge conflicts) may make your eyes bleed.Generally, you'll offer a program in source form via two methods:
Download of a release archive (e.g. foo-1.2.3-rc2.zip), this can contain the configure script.
Downloading the repository directly using Mercurial. If they want to work with that, they'll need to have autoconf installed.
In the root of my repositories, I usually include a file called
autogen.sh
that runs all of the steps needed (aclocal
,autoconf
, ...), which also handles alerting the user if they need something installed. I.e.Could not find tool aclocal, please install the autoconf package.
Its really best to just go with the
autogen.sh
method. This means only tracking configure.in (or configure.ac) and the associated Makefiles (from Makefile.in). Let each build configure their own, and provide adistclean
target to remove all filesconfigure
generates. Finally, provide amaintainer-clean
target to remove anything that the configuration suite itself generated, e.g.configure
.That should help make nightly builds easy.
您可以尝试设置一个预提交挂钩,如果在变更集中找到,它总是会恢复原始 Makefile 内容。
SO问题说明了读取变更集的内容坚定的。
确保使用预提交挂钩,并且不预提交。
You could try and setup a pre-commit hook which would always restore the original Makefile content if found in the changeset.
The SO question illustrates reading the content of the changeset to be committed.
Make sure to use the pre-commit hook, and not precommit.