libelektra
libelektra copied to clipboard
Integrate new 3-way merge into tools
Tools should be patched to use the new merge
- [ ] qt-gui (together with @darddan)
- [ ] elektrad (together with @raphi011)
- [ ] gsettings elektra_settings_backend_sync method (together with @mpranj)
- [ ] kdb import
- [ ] kdb editor
- [ ] kdb shell
- [ ] kdb mount
- [ ] kconfig (https://github.com/ElektraInitiative/kconfig together with @FelixResch)
- [ ] replace "kdb merge", remove "kdb cmerge"
Thank you for reporting this issue! I added a full list of all tools above.
Is there any example or documentation how to do this?
src/tools/kdb/cmerge.cpp is the only thing close to an example for this
I agree with @raphi011 there definitely should be a nice example how to use the API.
I added "kconfig (https://github.com/ElektraInitiative/kconfig together with @FelixResch)"
An example and a pkg-config file would really help to use this.
I fully agree, @raphi011 can you maybe add this pkg-config file as you already know how to do it and it would take @Chemin1 quite some time to learn about it.
Examples you have in #3235 and #3236
Examples you have in #3235 and #3236
Actually, #3235 does not have a call to elektraMerge yet. I'm not sure how implement the merge here yet but will take a look at it as soon as possible.
#3222 in contrast has one.
src/tools/kdb/cmerge.cpp is the only thing close to an example for this
"close to" might have been misleading. cmerge.cpp is an example, too.
it would take @Chemin1 quite some time to learn about it.
@raphi011 Thank you for #3241! @markus2330 is right, I have never done this before and no idea how it works.
@darddan, @FelixResch it would be great if you could take a look at those examples, too.
@Chemin1 I think all of these examples are not exactly what kconfig or elektrad need. What they need is something like what happens in the qt-gui.
Actually, you could fix examples/kdbset.c to call your API instead. This would be exactly what kconfig/elektrad will need. (Btw. the userInput would actually simply be passed to the strategy parameter of elektraMerge. The part with "problemKey" is now irrelevant, you can remove this.).
Sorry for not pointing out earlier that examples/kdbset.c exists. Maybe this example even replaces the need for an extra tutorial. Somehow we need to make this example more prominent, though: E.g. link from the merge tutorial and include in the kdbSet documentation. @Chemin1 can you do this?
@Chemin1 I think all of these examples are not exactly what kconfig or elektrad need. What they need is something like what happens in the qt-gui.
This would be very helpful. BTW: what is the expected strategy that elektrad should use for merging? ours?
elektrad, like qt-gui ideally escalates to the user and ask the user about how to proceed.
I think you will need some merge endpoint, and can send what the user wants as parameter.
Basically, something like this needs to be done:
- If any of the endpoints fail with a conflict (can only happen for the "non-get"), the user gets an popup that says that someone externally modified KDB
- the user selects one of the strategies, for now ours and theirs is enough
- when the user confirms, /kdbMerge (or similar name) is called, here a code like in examples/kdbset.c is executed (also a go binding for that will be needed, or maybe even better directly for the merge library)
I think all of these examples are not exactly what kconfig or elektrad need. What they need is something like what happens in the qt-gui.
Hmm ok. I'll have a look at qt-gui.
@raphi011 I hope the call in #3247 helps you a bit even if I'm confused by what we want to show with the example.
if I'm confused by what we want to show with the example.
What are you confused about? The example shows how an application/tool should call elektraMerge when kdbSet fails.
@Chemin1 seems like the list was not complete after all. I missed elektra_settings_backend_sync. It did not use the 3-way merging (mainly because it is C code and it would not be so easy to call the old merging API there but this is now, thanks to you, no longer an issue) but it has a TODO "conflict management" to be resolved. I added it in the top-post.
I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:
@Chemin1 any progress? It would be really great for 1.0.0 to get rid of the old merging code :sparkling_heart:
I'm sorry, but no real progress. I haven't found the time to do any side projects for months, unfortunately.
@atmaxinger do you want to take this issue?
Maybe as a low-priority issue, after the other stuff for recrod-elektra is finished.
Hopefully someone picks it as FLOSS project. I think it is important to get rid of the C++ implementation. It is very confusing that different tools use different merging implementations.
@atmaxinger is there anything else missing except of #4489 so that the C implementation is a full replacement for the C++ implementation? To fix #4489 would be a prerequisite to fully solve this issue.
Couldn't @hannes99 swap the merge implementation in kdb while moving to C?
@atmaxinger @hannes99 we should clarify who works on what here (and maybe split up the issue). Any suggestions?
Well I can definitely work on #4489 and @hannes99 could work on the tools integration?
We can also split up the tools integration if its too much work for @hannes99.
I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:
I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart: