On Wed, 25 Feb 2009 17:32:08 +0100 Dominique Dumont <dominique.dum...@hp.com> wrote:
> Harald Braumann <ha...@unheit.net> writes: > > > I don't really know Config::Model. But the main problem I have with > > the current system is, that I only see diffs between the currently > > installed version and the new package version. > > With ucf, you see a diff between current file (i.e. installed version > with your modifications) and the new package version. That I also see without ucf. > > No what I really would like to see is the diff between the last > > version I've merged and the new package version. > > 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. > > So changes can easily be seen (changes in defaults, new/removed > > parameters or just white-space changes?) and merging would work > > without a conflict in most cases. > > With Config::Model: > - you would not see white space or any other formatting difference > - your customized values would be merged into the new package file > (more accurately, loaded in Config::Model configuration tree using > the new package *model*). Thus you would see the delta between your > new file and the new default value. See this example of a screenshot > [1] where the config values different from "default" are shown with > a green arrow 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. > - 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. > > Config::Model could be useful in addition, but would it support > > such a work-flow? > > Provided I've understood correctly your work-flow, I'd say mostly > yes... 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? Cheers, harry
signature.asc
Description: PGP signature
