when you pull oldDoc and if the oldDoc has unresolved conflicts it will pick the deterministic winner by the rules below.
CouchDB guarantees that each instance that sees the same conflict comes up with the same winning and losing revisions. It does so by running a deterministic algorithm to pick the winner. The application should not rely on the details of this algorithm and must always resolve conflicts. We’ll tell you how it works anyway.
Each revision includes a list of previous revisions. The revision with the longest revision history list becomes the winning revision. If they are the same, the _rev values are compared in ASCII sort order, and the highest wins. So, in our example, 2-de0ea16f8621cbac506d23a0fbbde08a beats 2-7c971bb974251ae8541b8fe045964219.
You should have a process resolving conflicts on SG. Here is an example python script.
Just make sure it follows the same rules as CBL does on resolving conflicts.
NOTE in the up coming SG 2.x it will auto-conflict resolve , or you can use a custom one also.
One advantage of this algorithm is that CouchDB nodes do not have to talk to each other to agree on winning revisions. We already learned that the network is prone to errors and avoiding it for conflict resolution makes CouchDB very robust.
Users as in a backend Process feeding off the _changes feed?
User , CBL device resolving a conflict it being push back to SG?