Is there any explicit documentation of the algorithm CouchDB uses to pick the default “winning” revision of a document that’s in conflict? The closest I could find was in the documentation’s chapter on conflicts[1], but although it says several times that CouchDB picks a revision as the default one, it never says how it arrives at it.
This isn’t just an implementation detail, because it explains behavior that can seem weird to developers. This came up for me because I got a bug report saying that “deleted documents come back after a pull replication” — the replication pulled in a conflicting branch in which the document wasn’t deleted. The developer filing the bug report knew about conflicts, but their intuition was that since the local deleted revision was “deeper” (higher generation number) than the one pulled in, it would still win and the doc would still be deleted. Anyway, my understanding (as implemented in TouchDB/Couchbase Lite) is that the winning revision is picked by these rules, in descending order of priority: 1. A live revision wins over a deleted one. 2. Higher generation number [the numeric prefix of the revision ID] wins. 3. Lexicographically-higher revision ID wins. Amirite? (I arrived at this after a couple of explanations from Damien, but I still might have missed something…) Anyway, it would be nice to add this to the docs somewhere. —Jens [1] http://docs.couchdb.org/en/latest/replication/conflicts.html
