Slightly more precisely, _revs_limit affects the number of revisions kept for each edit branch. While Adam's point about the replicator is valid I don't think its quite the answer that Vladimir is looking for.
The compactor removes document bodies for each revision that is not a leaf of the revision tree during compaction. Thus your db won't be 1000x larger than it needs to be and setting _revs_limit lower won't save you that much on disk space. On Mon, Jan 20, 2014 at 8:36 AM, Adam Kocoloski <[email protected]> wrote: > On Jan 20, 2014, at 11:29 AM, Vladimir Ralev <[email protected]> wrote: > >> Hello all >> >> I was reading about _revs_limit >> <http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options> >> which >> defaults to 1000 or so here >> http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options >> >> It seems to imply that those 1000 revisions will be preserved even after >> compaction.Is this correct and does it mean that the database will be as >> much as 1000x bigger than it needs to be after compaction. >> >> I have a database that I want to perform maintenance on so i remove it from >> traffic and want to reduce the number of revisions to 1 again safely. Is >> there some shortcut to do that? > > Hi, that setting controls the number of revisions about which the server > keeps a record, not the number where the actual body of the rev is preserved. > Compaction only ever preserves the last revision of each edit branch; this > is not configurable. The _revs_limit setting impacts replication, e.g. if > you make 1001 edits on a source server in between replications to a target > the replicator will not be able to piece together edit 1 and edit 1002 and > you'll end up with a spurious conflict on the target. > > Adam
