Harald Braumann <ha...@unheit.net> writes: >> I fail to see the differences (no pun intented) between "the last >> version I've merged" and the current file ... > > I mean the last maintainer version I merged into the installed version, > not the result of the last merge.
ok > But there are 3 possible situations here: > 1. value has been changed between the last and the new maintainer > version > 2. value was modified locally > 3. both of the above > > In case 1 the modification could be merged silently, in case 2 the > modification should be left alone and in case 3 I'd have to decide what > to do. Config::Model on its own couldn't tell the difference. Currently a maintainer set some value in a package config file to reflect his decisions or debian policy or whatever. With Config::Model such decision would not be encoded in the delivered config file but in the model of the configuration file. This would be specified in the configuration model as a default value. Here's what will happen during an upgrade: a. Config::Model will dump customized value somewhere (dump values which are different from maintainer's model version N. i.e. this will keep track of values from case 2 and 3 *if* they are different from the default value specified in the old model version N ). b. application model is upgraded from N to N+1 (case: 1 and 3: some default config values are changed) c. Config::Model performs the merge: * case 1: no customized value stored in step a. Config::Model will write the default value (specified in the new model version N+1) in the config file * case 2: customized value stored in step a. is loaded, checked and will be written in configuration file * case 3: just like case 2 I hope this replies to your concerns. If not feel free to ask more questions. >> - yes, merging would work mostly without conflict > >> >> > Similar to like SCMs work. >> >> The main difference between a SCM and Config::Model is that a SCM >> works purely at text level without knowledge of the semantic of the >> file under control. OTOH, Config::Model uses the semantic knowledge >> provided by the model to perform the upgrade. > > You could apply the way merges work in an SCM to structured > information. More often than not, the order of the configuration data is not important. For SCM merge, this order *is* important. > Having the diff between the last and the new maintainer version is not > an alternative to Config::Model. The former can tell me what has > changed in what way and the latter can present this information > enriched with its semantic knowledge of the changes. Both are things I > find useful. So my question is, if Config::Model can also deal with the > additional information of what has changed how, so the two things could > be combined? Config::Model can only show the diff between the current state (current file or file + modifications) and the default values from the configuration model. There's no notion of history or diff with previous version of a configuration file. Well, not yet. I'll have to think about this... All the best -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org