couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Which revisions does _revs_limit prune?
Date Sat, 31 Aug 2013 18:06:40 GMT
and "age" of a revision is its depth, not how recently it was
transferred in a PUT operaiton.

B.

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 the
> %% 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. if 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 number of document
revisions that will be tracked by CouchDB, even after compaction has occurred." Nothing I've
been able to find online says which revisions are thrown out to reach this limit — it could
be the oldest ones, or the ones most deeply buried, for example.
>>
>> I’m guessing it’s most likely the oldest [earliest added] revisions, but it’s
not always clear what those are. For example, if a document with a big rev tree gets replicated
into this database, all of its revisions are 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?
>>
>> —Jens

Mime
View raw message