kconfig-elektra

[David Faure]

On samedi 16 novembre 2019 12:22:08 CET kde5 at markus-raab.org wrote:
> >> 2. If Elektra finds a merge conflict between the KConfig objects and the
> >> 
> >>    configuration files on the disc, should we then do a 3-way merge
> >>    which prefers "ours" or should we ask the user with a KDialog how to
> >>    proceed?
> > 
> > what's the scenario that might lead to this happening?
> 
> Someone presses "save" in a configuration dialog but this change would
> overwrite another change in the configuration file done by another
> process (e.g. another application (instance), some CM tool, manual
> modification of the INI file, ...).
> 
> Steps to reproduce such an issue:
> 1. Start the application, let us assume this is the only point in time
>    where the application reads the configuration.
> 2. Modify the INI file of the application externally.
> 3. Press save in the configuration dialog of the application.

(IIRC) what KConfig does in such a case, at step 3, is to reload the file from 
disk but without touching the entries marked as dirty (i.e. modified by the 
configuration dialog), and then save the result.
I.e. this will overwrite entries modified by both, but preserve entries 
modified externally and not modified by the application.

The comment at the top of KConfigIniBackend::parseConfig (and near the call to 
that method) confirms this.

I can't pinpoint the actual logic in the code itself though (I don't know it 
in full details).

I strongly suggest that the elektra backend has the same logic, it has worked 
well for 20 years.

> > It sounds to me like a dialog would bother the
> > user with low-level technical things that they won't understand nor know
> > how to resolve.
> 
> In the case the person had manually edited the INI file (or used Elektra
> to modify the configuration) him/herself, he/she would understand. If
> some other tool changed the INI file, it would be exactly as you say.

Yep, and we have no way to know which one it is, so let's play it safe.

> > If you can describe how this can happen, then we can conclude what
> > should be happening automatically to fix the situation.
> 
> Unfortunately, we cannot know if the "other change" happened by the user
> him/herself or by some script the user is not aware of.
> 
> The current situation is that *all* changes some other process did are
> lost. 

Not good, worse than the INI backend.

> In Elektra and automatic 3-way merging in favor of "ours", you
> will only lose changes in which there are actually conflicts.

Sounds good.

> So it will
> already be an improvement -- even without a dialog. If you do not want
> to lose *any* changes, an interaction is needed (like "git merge" has).

I don't think we need this. If I check a checkbox in a dialog, then I want 
that option to be ON, I don't need to confirm that again in a different 
(merge) dialog.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5