0

I have a project, hosted on launchpad, which contains a fairly user-specific configuration file.

Once the project is initially checked out, obviously this .cfg file should also be downloaded. However, further updates (via "bzr update") would ideally not alter this .cfg file, as the user would have made their own edits to it. These edits would be overridden / merged should (with potential conflicts) I push an update using the code with my own .cfg file - I don't want this to happen!

What's the best practice to avoid this? I can't really "bzr ignore", as then any future users checking out via bzr would then not have the .cfg file.

I could, of course, replace my .cfg file with the "stock" one each time I do a commit, but this seems a bit clunky.

Or equivalently clunky, supply the .cfg file separately.

What I'm looking for is a "single-shot" download, but never update subsequently.

Any advice?

Dave
  • 6,184
  • 8
  • 26
  • 28

1 Answers1

1

This is a tricky problem, because version control systems in general are not engineered to have the fine-grained commit strategies needed for this approach. If you were operating in a controlled environment, you could use plugins or hooks to exclude certain files from commits etc., but that doesn't seem to be an option here. I'll add that bzr ignore won't help you, either, because it only prevents files from being added; it doesn't prevent commits or checkout of those files.

What you can do is generate the config file during build/setup/installation if it doesn't already exist. Something like:

#!/bin/sh
if [ ! -e configuration.cfg ]; then
  cp etc/configuration.cfg.in configuration.cfg
fi

Here, you'd check in etc/configuration.cfg.in normally and run the above script at build/setup/installation (this could also be automated by a post_change_branch_tip hook in a controlled environment). You'd put the original in a different directory so that there's less of a risk of it getting edited by accident.

Reimer Behrends
  • 8,600
  • 15
  • 19