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 NXXXXXXX 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
