Hi, Jens. Well, I was going to link you to my investigation in Gist; however it looks like you have already seen it.
https://gist.github.com/jhs/1577159 On Thu, Oct 10, 2013 at 10:52 AM, 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
