Open meejah opened 1 year ago
For the filesystem API, I believe the way that worked before is that you would fix up "the" file however you liked, and then delete all the relevant conflict-marker files.
(On a local scan, we could notice this situation: the database says "foo" is conflicted, but there are [no longer] any conflict-markers for it -- so we take all the conflicting remotes, produce a new Snapshot with them as parents etc etc)
The HTTP API design is somewhat easier: we make an endpoint that declares "here is a resolution for the conflict on foo
" -- which I would propose at first takes a single revision, e.g. ours
or theirs=participant-name
. Then all the content of that Snapshot is considered the resolution.
We could introduce more args (or a different API) extension in the future to allow a more-complex resolution (e.g. "here are the bytes that constitute the resolution").
Currently, it is possible to detect and produce conflicts. These produce a database entry, are listed by the API and make "conflict" files in the filesystem.
There is not an API to resolve these conflicts. We likely need two:
See also #102