Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 70122 invoked from network); 24 Feb 2009 02:31:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 24 Feb 2009 02:31:32 -0000 Received: (qmail 32315 invoked by uid 500); 24 Feb 2009 02:31:32 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 32281 invoked by uid 500); 24 Feb 2009 02:31:31 -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 32269 invoked by uid 99); 24 Feb 2009 02:31:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Feb 2009 18:31:31 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=FS_REPLICA,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.68.5.17] (HELO relay03.pair.com) (209.68.5.17) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 24 Feb 2009 02:31:22 +0000 Received: (qmail 40356 invoked from network); 24 Feb 2009 02:30:59 -0000 Received: from 96.33.90.152 (HELO ?192.168.1.195?) (96.33.90.152) by relay03.pair.com with SMTP; 24 Feb 2009 02:30:59 -0000 X-pair-Authenticated: 96.33.90.152 Message-Id: <40C350F3-9A18-48D4-99BC-98519C601577@apache.org> From: Damien Katz 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 v930.3) Subject: Re: Fail on a simple case on replication Date: Mon, 23 Feb 2009 21:30:59 -0500 References: <22ECC59F-F646-4F07-9332-14371BA930BE@apache.org> <7060483c0902230711r3b02f2e5n9ebf5671aaa35c73@mail.gmail.com> <6092422F-29C3-4E5D-B26C-9C0E8B2E9FB4@apache.org> <64a10fff0902231502n317456f8l80a9d19c36b704aa@mail.gmail.com> <3C3204C0-0662-4012-B62B-9FA8643F4BC8@gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On Feb 23, 2009, at 8:45 PM, Chris Anderson wrote: >>> Would it be overly difficult to just add in the ability to keep a >>> full rev >>> history based on a config setting? > > This would be a pretty big change. As Antony says, once you go down > that path a little, you end up at something that is not really much > like Couch. > > There's yet to be a really clear reference for how to do > application-versioned documents in CouchDB. Hopefully we'll address > the topic in the book, but we haven't gotten that far yet. > > The way I see it, the salient options are: > > A) leave it as _rev and answer the versioning question every week > forever > B) rename it to _mvcc or _lock or _token or something else that > doesn't confuse people > > The main drawback of B is that when we start renaming _rev, someone > else comes along and tries to take the opportunity to change _id, or > otherwise change the whole system. If we can stick to just renaming to > something clearer, I'm happy to go ahead with this. I forgot when I posted this, we still need the ability to get conflict revisions, which also uses the ?rev=... syntax. Maybe we should change that use from ?rev... to ?conflict=...., since those rev ids show up in the _conflicts doc member. I think if we change from _rev to something else, _cc for concurrency control is good. I'm not sure this is necessary. Maybe we should only allow the ability to getting old revisions (? disk_rev=...) with a setting in the ini, defaulting it off. That discourages it's use as general purpose mechanism, but is easy to turn on if you really need it. -Damien