couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Documentation of winning-revision algorithm?
Date Thu, 10 Oct 2013 16:14:00 GMT
Hi, Jens. Well, I was going to link you to my investigation in Gist;
however it looks like you have already seen it.

On Thu, Oct 10, 2013 at 10:52 AM, 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]

View raw message