On Sat, 01 May 2010 19:18:55 +0200, Junio C Hamano <gitster@xxxxxxxxx>
wrote:
Thank you for the detailed explanation!
This design constraint makes the issue not a version control problem but
more of a software engineering problem. The changes to your parameter
file have its own history (e.g. you upgraded your machine last week with
different hardware---the software didn't change but the parameter has to)
and the history is largely independent of the software that reads the
file. In that sense, you should _never_ tie its history with the history
of your software.
Ok.
At the same time, the history of the parameter file is not completely
independent of that of the software. You may have added a new feature
and code to read a new setting in the parameter file today and older
parameter file would not have a setting for that variable.
Exactly.
The method I used in my day-job project is something like this:
- Include a "config.sample" file and track it in the history of the
source code; the values it gives to the variables are the same as the
default ones. This file mostly serves as a documentation.
I actually did exactly that already (but forgot to mention it in my first
mail, sorry!). The problem with this "one" config.sample is, that I need
about three really different config files because of really different
sensor setups on about five different computers. So when I push on a USB
stick, walk to another computer, then pull and try to run the software -
bummer, forgot to copy the current config file - walk back, copy ...
But maybe the solution below solves this too. Or I write a little script
doing the push and parameter file copy.
- Design your parameter mechanism in a way that:
- a parameter file can include another;
Can't do that yet.
- an unrecognized parameter setting is ignored;
Can do.
- a variable definition that happens later overrides an earlier
definition.
Can do.
- Have a real parameter file that is _not_ tracked in the history of the
source code. Have it include parameter.sample and then define machine
specific settings after that to override.
Good idea.
It is only required for the "real" parameter file not to be tracked in
the history of the source code---it is perfectly fine to track it in a
separate history. The easiest way to do this would be to keep a
parameter working tree next door, and "ln -s ../params/config config" in
the working tree for the source code. You could keep this symlink
tracked in the
source history, but you do not have to.
I see. So if I want parameter file history the only proper solution is to
have a separate parameter file git repo, right?
You will try to read from ./config, which will include ./config.sample in
order to read the default, and then read the customized setting that
appear later in ./config. Because of the symlink, you will actually be
reading from ../params/config next door.
Ok, will give it a try.
--
Regards,
Tilo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html