On Thu, Oct 10, 2013 at 5:52 PM, Jens Alfke <[email protected]> wrote:
> 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 maybe that helps: https://github.com/refuge/rcouch/wiki/Replication-Algorithm
