Implementing Merge: Version history stored in Couchbase Lite?

We are using Couchbase Lite in a mobile app, so users can use it online or offline (and synchronize later).
However, this create possibility of conflicts, so we have to implement a Merge logic.

We were thinking something like:
Lest say I have two devices: X and Y, and both of them have the version 3 of a document.
Then, they both go offline and edit the document creating their on versions: 4_x and 4_y.
Then, they both go online and we get the conflict, and we have to program the logic for the merge.

Does the Couchbase Lite that i have in the device, keep a history of the parent of the conflicting versions? (in this case, version 3)
IT would be very beneficial for us to have available the parent of a conflicting version, so we can know what changed from version 3 to version 4 and then decide what to do.

Or… is there a better way to implement the merge? (that would be great…)

As far as I’m aware, you aren’t always guaranteed to be able to do this. See

In my application, I ended up having to resolve conflicts by using a ‘newest edit wins’ approach. This is not ideal, but it’s the only thing that I’ve been able to get to work reliably.

If rev 4_x and 4_y have property ‘abc’ that has different values, you don’t know which one changed and which one did not without the common ancestor, hence you can’t do a smart merge.

Bad news… but thanks a lot for the feedback and the link, that will give us a solid starting point!

Yes, Couchbase Lite keeps the revision history for this purpose. You can easily look at the revisions from the Document class and do things like finding the common ancestor.

What’s not guaranteed is that the body of the common ancestor revision is still available. CBL isn’t a version-control system like Git, and storage would go out of control if every revision of every document were kept around. Instead, non-leaf revisions’ bodies are removed when the database is compacted.

With SQLite storage, compaction is (currently) only manual, so no revision bodies get removed until you manually call Database.compact. With ForestDB storage, compaction happens automatically in the background.

Excellent! Thanks a lot!

The n-way merge for conflict resolution section of the training might help

Which platform are you developing on?