views:

169

answers:

2

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?

A: 

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.

VonC
+2  A: 

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 in configure 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 a distclean target to remove all files configure generates. Finally, provide a maintainer-clean target to remove anything that the configuration suite itself generated, e.g. configure.

That should help make nightly builds easy.

Tim Post
Tim's dead right. Don't keep in the repo anything that can be automatically generated, and if you do (for backup?), keep them in a separate directory where they won't be picked up / run in normal usage.
Ry4an