3

Possible Duplicate:
how to ignore files in kiln/mercurial using tortoise hg “that are part of the repository”

I have a config file that I don’t wish to check in however I do wish to get updates whenever someone checks in a change to it.

In most systems I just need to uncheck the tick mark next to the config file at check-in time, however HG seems to make life a lot harder!

In parforce this even easier, I can just check the config file out in a different change list, how do I do the same in TortoiseHg?

Community
  • 1
  • 1
Ian Ringrose
  • 49,271
  • 50
  • 203
  • 302

2 Answers2

4

In general, you don't. The usual way to handle this is not to put the config file in source control, but instead to put a template for it in source control. Something like config.sample. You can even tweak your run/build script to copy config.sample to config if config doesn't already exist.

There are plenty of other ways to try and get at this using mq or an alias like mycommit = commit -X config, but at its core a file is either tracked or it isn't and a file everyone has to change themselves shouldn't be.

Ry4an Brase
  • 77,054
  • 6
  • 143
  • 167
  • I can agree in principle, but its a file that needs tracking for default configuration and only 1 line needs changing each time in this instance. – Adam Houldsworth Apr 13 '12 at 16:30
  • 1
    I think Ry4an is right, it is tracked or it isn't. Another workaround I suggest is to have two config files rather than one. The first is the "global" config (which is versioned) and the other "local" config file is totally optional (and is not versioned and is ignored). The local config file's values would simply be there to override the global config's values. I don't know what programming language you are using but several languages have easy ways to do this. In python it is config = ConfigParser() config.read(['master.conf','local.conf']) – shaune Apr 13 '12 at 19:15
  • @AdamHouldsworth yeah, that's hard. Ideally I'd use an include (`%include config-$HOST`) or overlay (load `config` and then load `config.local` over top of it if it exists, but that requires a flexible config system or one you can modify to become flexible. At any rate Mercurial isn't going to make it easy to have a file that's tracked, edited, but never committed -- it's just not what they seek to make easy. :( – Ry4an Brase Apr 13 '12 at 21:35
  • Its C#, something like this should be possible. Well worth looking into. – Adam Houldsworth Apr 14 '12 at 08:36
  • Or can you de-reference environment variables where you load that value. Allowing DATABASE_PATH to override the value in the file lets developers set their own environment at the system level and leave the file unpersonalized. – Ry4an Brase Apr 16 '12 at 16:37
2

If you uncheck the file from the file list before committing it won't go into the change set. This means it won't feature in a push (as these are per change set).

This is one feature of Tortoise that makes it useful over the command-line.

If you do a pull with an edited file, you will create multiple heads. You can merge these if you want the file to feature changes, but this might be a manual step.

Alternatively in the case of a config file it is useful to use the Patch Queue functionality of Mercurial. From the command-line this is possible thus (assuming it is changed in your working directory):

hg qnew "localConfig"
hg qrefresh

This creates a new patch queue item called "localConfigs", and puts the edited files (your config file) into the item. You can then:

hg qpop

To remove it from the patch queue (out of your change set path). Or:

hg qpush

To put it in your change set path. This is an easier way of managing file changes that you do regularly on top of keeping pace with the central repository: you pop your queue items out, pull and update, then push the queue items back on (handling any merge conflicts, though these are rare if your items are small). This way you avoid multiple heads.

https://www.mercurial-scm.org/wiki/MqExtension

We tend to use this mechanism in our office.

Note, pushing and popping acts like a stack collection; if "localConfigs" is on top of "moreLocalChanges" you will need both if you wish to push "localConfigs". My example assumes that the "localConfigs" patch is the only one in the queue. It is also disabled by default in Mercurial configuration, but comes bundled with it so you can enable it simply:

[extensions]
mq =
Vadim Kotov
  • 7,103
  • 8
  • 44
  • 57
Adam Houldsworth
  • 60,104
  • 9
  • 137
  • 177
  • The command line offers that too with `-X` on commit. – Ry4an Brase Apr 13 '12 at 16:07
  • Yeah but its a little easier with the UI. – Adam Houldsworth Apr 13 '12 at 16:28
  • Sure, I took "This is one feature of Tortoise that makes it useful over the command-line." to imply you can't do it with the command line, when with an alias (or a forbidden [defaults] block) you can do it with less effort -- though I still think one should just exclude the file from tracking as most major projects do. – Ry4an Brase Apr 13 '12 at 16:34
  • Sorry, I was also implying that clicking checkboxes is easier than typing full file paths. – Adam Houldsworth Apr 13 '12 at 16:35