Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAD2UGCVZsjWo7vaJJ+5MGbPBSn+mBzYQ=SYXcf_9UEfQpqugJw@mail.gmail.com>
References: <40D9BD04-119C-4912-8F30-688F76FFC444@couchbase.com>
	<CABvT1DH6jzeRUX3R1g-zi1B6vZXLRu0O9aWFWJc5dDzXoYQ7xg@mail.gmail.com>
	<CAD2UGCVZsjWo7vaJJ+5MGbPBSn+mBzYQ=SYXcf_9UEfQpqugJw@mail.gmail.com>
Date: Sat, 31 Aug 2013 19:14:20 +0100
Message-ID: 
 <CAD2UGCUfZJnJstpQWESFtU5GOnEy05dvvM2JJ9p+HXFtVUX12Q@mail.gmail.com>
Subject: Re: Which revisions does _revs_limit prune?
From: Dale Harvey <dale@arandomurl.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=047d7b6d88c8e4272004e5424e71

--047d7b6d88c8e4272004e5424e71
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

* stem the tree by turning the ...


On 31 August 2013 19:13, Dale Harvey <dale@arandomurl.com> wrote:

> So the way I implemented this in PouchDB gives Paul Davis's advice, is to
> stem the trees but turning the revision tree into a set of revision lists=
,
> listing all the individual paths from head to root, then stemming each li=
st
> to the rev limit, then merging them back into a single tree
>
> I worked off a refactor branch of couch that never got merged, but from a
> glance it looks like this is how it is done in
> https://github.com/apache/couchdb/blob/master/src/couchdb/couch_key_tree.=
erl
>
> I keep meaning to write a test to reproduce this, but I am fairly certain
> this has the problem with a document that is generating a lot of conflict=
s
> (by being deleted and recreated continuously), can dos CouchDB as shallow
> branches never get pruned, but I may possibly be missing something
>
>
>
> On 31 August 2013 19:05, Robert Newson <rnewson@apache.org> wrote:
>
>> The best I can find right now is from couch_key_tree where the
>> truncation occurs;
>>
>> %% What makes this a bit more complicated is that there is a limit to th=
e
>> %% number of revisions kept, specified in couch_db.hrl (default is 1000)=
.
>> When
>> %% this limit is exceeded only the last 1000 are kept. This comes in to
>> play
>> %% when branches are merged. The comparison has to begin at the same
>> place in
>> %% the branches. A revision id is of the form N-XXXXXXX where N is the
>> current
>> %% revision. So each path will have a start number, calculated in
>> %% couch_doc:to_path using the formula N - length(RevIds) + 1 So, .eg. i=
f
>> a doc
>> %% was edit 1003 times this start number would be 4, indicating that 3
>> %% revisions were truncated.
>> %%
>> %% This comes into play in @see merge_at/3 which recursively walks down
>> one
>> %% tree or the other until they begin at the same revision.
>>
>>
>> On 31 August 2013 19:02, Jens Alfke <jens@couchbase.com> wrote:
>> > The only description I can find about revs_limit is "the maximum numbe=
r
>> of document revisions that will be tracked by CouchDB, even after
>> compaction has occurred." Nothing I've been able to find online says whi=
ch
>> revisions are thrown out to reach this limit =97 it could be the oldest =
ones,
>> or the ones most deeply buried, for example.
>> >
>> > I=92m guessing it=92s most likely the oldest [earliest added] revision=
s,
>> but it=92s not always clear what those are. For example, if a document w=
ith a
>> big rev tree gets replicated into this database, all of its revisions ar=
e
>> the same age as far as the local db is concerned, because they all got
>> added in the same PUT operation.
>> >
>> > Anyone know for sure?
>> >
>> > =97Jens
>>
>
>

--047d7b6d88c8e4272004e5424e71--