From dev-return-5878-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sun Aug 16 14:38:44 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 28152 invoked from network); 16 Aug 2009 14:38:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Aug 2009 14:38:44 -0000 Received: (qmail 77079 invoked by uid 500); 16 Aug 2009 14:38:50 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 76994 invoked by uid 500); 16 Aug 2009 14:38:50 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 76982 invoked by uid 99); 16 Aug 2009 14:38:50 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Aug 2009 14:38:50 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.97.50.139] (HELO jan.prima.de) (83.97.50.139) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Aug 2009 14:38:40 +0000 Received: from [10.0.1.3] (i59F4F1A8.versanet.de [::ffff:89.244.241.168]) (AUTH: LOGIN jan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by jan.prima.de with esmtp; Sun, 16 Aug 2009 14:38:18 +0000 Message-Id: <2C9E0407-E0A2-442C-8525-D7A40944FB91@apache.org> From: Jan Lehnardt To: dev@couchdb.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: History Proposal Date: Sun, 16 Aug 2009 16:07:08 +0200 References: <20090806200159.GB21583@uk.tiscali.com> X-Mailer: Apple Mail (2.935.3) X-Virus-Checked: Checked by ClamAV on apache.org On 15 Aug 2009, at 19:02, Jason Davies wrote: > On 6 Aug 2009, at 21:01, Brian Candler wrote: >> On Thu, Aug 06, 2009 at 05:04:34PM +0100, Jason Davies wrote: >>> The other good thing about storing historical >>> versions as attachments is that they would get replicated. >>> Currently we >>> don't replicate old MVCC versions, this would have to change as >>> well as >>> preventing them from being compacted as you say. >> >> However, we do replicate old MVCC versions if they are conflicting, >> and we >> do keep them through compaction. >> >> Perhaps "conflicting" and "historical" could be treated in roughly >> the same >> way? >> >> You resolve conflicts by deleting the conflicting rev(s). This >> could be done >> for deleting historical versions too. > > Do we want deletions of historical versions to be replicated too? > For example, if I "permanently delete" a bunch of old versions on my > local machine, and then replicate to my master server, should the > master server also delete these old versions? This would be > analagous to deleting conflicting revs. I can see that in some > cases this may not be desired e.g. if someone is simply trying to > free up space, and they would prefer the master server to preserve > all revisions. Is it possible to write a validate_doc_update function that would deny historical revision deletes from replicating? If yes, I'd say that's the answer for a server that is designated to keep all revisions. Cheers Jan --