Resolve primary key conflicts in multi-user scenario

[EPajares]

Thanks for building this nice tool! Actually, we are using it to maintain our Points of Interest database. We have several people editing the data, and there is where we currently face an issue.

Is your feature request related to a problem? Please describe.
Let's say user 1 works in his fork and adds data to the table. The data is inserted and gets automatically populated with a primary key that is serial. When user 2 does the same simultaneously, the inserted features get the same ID. As a result, when merging the data, there is a conflict and violation of the primary key.

Describe the solution you'd like
It would be good to have a way to resolve this automatically. At least we face this problem each time, different people work simultaneously on the same data set. Or is there any way to do this already?

Describe alternatives you've considered
Currently, we are just producing with quite some effort revision that sort out the conflict.
Additional context
We are running it using PostGIS for the working copy.

I would be very happy about any indication!

[olsen232]

Servus! We're aware the conflict resolution is still, shall we say, minimal viable product. There's a laundry list of possible improvements to it at #113.

The one that describes your situation - perhaps the most important from the original ticket - is listed as "add support for resolving add/add conflicts by renaming one of the features automatically".

Suppose you could resolve all of the "add/add" conflicts (that is, conflicts where both branches have inserted something unrelated) with a single command - let's say it's kart resolve --renumber=theirs (the exact command is TBD). This would keep all of the "ours" primary keys as-is, and renumber all of the conflicting "theirs" primary keys, allowing you to move forward with the merge.

Something it would not do is allow you to maintain two different branches with conflicting primary keys going forward - the appropriate flow would be for one user to merge, resolve all the add/add conflicts, and then use the merge commit as the starting point for any further changes they make. The incorrect flow would be for two users to both independently make a whole sequence of commits - which when merged together, cause add/add conflicts - and one user tries to merge the other users' work to their branch, one commit at a time. (This flow also works poorly in Git - you can try it out in Git right now to get an idea of it).

Would this be sufficient for your use case?

[EPajares]

Servus :) Thank you very much for your reaction. This seems excellent to me. I saw you have actually started implementing it already. I am very curious to test this, kindly let me know if I can help with something.

[olsen232]

Fixed by #817 - open a new issue if there's any problems with it or to request a further enhancement