Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 045CB10DE1 for ; Fri, 31 Jan 2014 23:42:32 +0000 (UTC) Received: (qmail 69841 invoked by uid 500); 31 Jan 2014 23:42:30 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 69776 invoked by uid 500); 31 Jan 2014 23:42:30 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 69766 invoked by uid 99); 31 Jan 2014 23:42:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jan 2014 23:42:30 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of adam.kocoloski@gmail.com designates 209.85.216.54 as permitted sender) Received: from [209.85.216.54] (HELO mail-qa0-f54.google.com) (209.85.216.54) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jan 2014 23:42:25 +0000 Received: by mail-qa0-f54.google.com with SMTP id i13so7255790qae.27 for ; Fri, 31 Jan 2014 15:42:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=O8XKsaI7uMtuUmRm3j52uxFxBhM78koel/Jm66+scY4=; b=Q2HzTPCfmaAQWz87lWOkqJtamJzOpuPYzC7MVvQ3N/5EdnKGGk4gjiX+gB75n0xxVA s2snouHMkJmRKt68ZWOz5M2nE77hUZ6R87ripuSSeOepyFD69NTe+6FSkW/gI/GmVtw5 v/12uxjQdC1VB33dWZhD93i7BXulJVHBnXNLZblBfhdhIQ8zEB/79Ta4uP3U8kx9Qahm jaT9uD0ntLfmOfFpsNRF/ZxNYU44rQkuGllq4ft8O6lWUnSUPqnh1x7Zj9cFR57sq5tN bV2c2dlI7m1XMx188x/w4I8J+vxOkMSUNJotWGAKZtmeMHE9JcFVlNozxcsRJ9+TTzZQ 5rqw== X-Received: by 10.140.47.212 with SMTP id m78mr34339355qga.21.1391211724489; Fri, 31 Jan 2014 15:42:04 -0800 (PST) Received: from [172.16.9.136] (cloudant03.c.subnet.rcn.com. [146.115.6.130]) by mx.google.com with ESMTPSA id u75sm15635051qgd.23.2014.01.31.15.42.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Jan 2014 15:42:00 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Revisions lost on CouchDB 1.2.0 From: Adam Kocoloski In-Reply-To: Date: Fri, 31 Jan 2014 18:41:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References:

To: user@couchdb.apache.org, lmorandini@ieee.org X-Mailer: Apple Mail (2.1827) X-Virus-Checked: Checked by ClamAV on apache.org On Jan 31, 2014, at 6:36 PM, Luca Morandini wrote: > On 31/01/14 19:42, Robert Samuel Newson wrote: >>=20 >> As Simon says, this is the normal and expected behavior of CouchDB = after >> database compaction (or replication). CouchDB is not a revision = control system, >> it only keeps the latest versions (including conflicts) of every = document >> (including deleted ones). >=20 > Compaction was indeed run (the sysadmin has no recollection of it, but = it is shown in the logs, my bad I overlooked it). >=20 > I interpreted the _revs_limit parameter as the number of revisions to = keep (including their data), or does CouchDB keep metadata only after a = compaction ? >=20 > Regards, > Luca Morandini Correct, _revs_limit controls the number of revisions about which = metadata is kept. It's relevant for replication -- if more than = _revs_limit updates are applied in between replications to a target DB = spurious conflicts can be generated. Compaction only ever preserves the body of the latest revision on each = edit branch. Adam=20=