Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jens@couchbase.com designates
 206.225.164.28 as permitted sender)
From: Jens Alfke <jens@couchbase.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Date: Thu, 10 Oct 2013 08:52:35 -0700
Subject: Documentation of winning-revision algorithm?
Thread-Topic: Documentation of winning-revision algorithm?
Thread-Index: Ac7F0L3FF/ckEV4nQPuzW4c2Aj5P/g==
Message-ID: <CFBDC5A8-036E-4B9F-A2F2-243ADD5D19BC@couchbase.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Is there any explicit documentation of the algorithm CouchDB uses to pick t=
he default =93winning=94 revision of a document that=92s in conflict? The c=
losest I could find was in the documentation=92s chapter on conflicts[1], b=
ut although it says several times that CouchDB picks a revision as the defa=
ult one, it never says how it arrives at it.

This isn=92t just an implementation detail, because it explains behavior th=
at can seem weird to developers. This came up for me because I got a bug re=
port saying that =93deleted documents come back after a pull replication=94=
 =97 the replication pulled in a conflicting branch in which the document w=
asn=92t deleted. The developer filing the bug report knew about conflicts, =
but their intuition was that since the local deleted revision was =93deeper=
=94 (higher generation number) than the one pulled in, it would still win a=
nd 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 prio=
rity:

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=85)
Anyway, it would be nice to add this to the docs somewhere.

=97Jens

[1] http://docs.couchdb.org/en/latest/replication/conflicts.html=