couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Documentation of winning-revision algorithm?
Date Thu, 10 Oct 2013 16:57:24 GMT
On Thu, Oct 10, 2013 at 5:52 PM, Jens Alfke <> 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]

maybe that helps:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message