From dev-return-2935-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Feb 25 04:25:49 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 84704 invoked from network); 25 Feb 2009 04:25:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Feb 2009 04:25:49 -0000 Received: (qmail 18139 invoked by uid 500); 25 Feb 2009 04:25:48 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 18101 invoked by uid 500); 25 Feb 2009 04:25:48 -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 18090 invoked by uid 99); 25 Feb 2009 04:25:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Feb 2009 20:25:48 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FS_REPLICA,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates 209.85.200.170 as permitted sender) Received: from [209.85.200.170] (HELO wf-out-1314.google.com) (209.85.200.170) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Feb 2009 04:25:40 +0000 Received: by wf-out-1314.google.com with SMTP id 28so3123933wff.29 for ; Tue, 24 Feb 2009 20:25:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=c2EVgWw1Y44dnT4NdyXUBMF6Dk3Gn3KPj5Iug/EZrzw=; b=jYmQSF82qajuIJ1d44imxulRN3pIRfCGjOb5LxV5RHLqkjHXsvZCcpKP6jBpkVKCHI Ra1FfKBLW0Oky4/HS50mNo0gzOTPIgf+K4WL6vSjLuQQeMxvpAZ7PG+UbDQcwz7TalLI bVL1BYZu4FqH2RJobbYhR9FjjJRCylu652hho= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=rX16rg0dr0cIcgQJczzO4Y1GLQKotSEeIF0WQLndiDL52J/X5pe2rrqK/UthYk+reB jKhPI8qmSH+Gvr3JxwzcMdyqfPsVBZ3UqPVQ6ln6fGHVSSiv9iyoJPp2Q8ExgY95KTr5 G4wIUImKDa3IX2dtVoWmJWZ9k9bjMeyTcwRLg= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.142.125.9 with SMTP id x9mr2912602wfc.38.1235535919724; Tue, 24 Feb 2009 20:25:19 -0800 (PST) In-Reply-To: References: <6092422F-29C3-4E5D-B26C-9C0E8B2E9FB4@apache.org> <64a10fff0902231502n317456f8l80a9d19c36b704aa@mail.gmail.com> <3C3204C0-0662-4012-B62B-9FA8643F4BC8@gmail.com> <60EAEE6E-E496-44C0-9D75-C67D8FB36D6A@apache.org> <0D88B212-B1DF-41A6-B407-C8809C3E203D@gmail.com> <486F7275-A60E-497C-86C5-CAC7FE3F2B7C@apache.org> <74159816-3CFD-4575-B71C-64C3A741EDDD@gmail.com> <0EFFA3EF-E57A-4174-99C0-88A32F33626A@apache.org> Date: Tue, 24 Feb 2009 20:25:19 -0800 X-Google-Sender-Auth: 1cbd7c2706139b35 Message-ID: Subject: Re: Fail on a simple case on replication From: Chris Anderson To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Feb 24, 2009 at 9:52 AM, Chris Anderson wrote: > On another note, I was thinking about it some more, and I think that > renaming _rev to _cc would be a huge pain in the ass for a lot of > people (who don't go around abusing it) and it can probably be > avoided. > > The only valid use case for requesting a particular _rev of a > document, is in resolving conflicts introduced by replication. So if > we restrict access to old revs (by default) to an endpoint which gives > an array of documents (each conflicted rev) then it won't be usable as > a revision control system, only as a conflict resolution system. If > there's not an easy way to think you have implemented a version > control system (eg no API endpoint for accessing non-conflicting revs) > I bet we'll see misapprehension of _rev happen a lot less. > Trying to get this thread back on track about an actual small concrete change to the code we could make that might keep people from trying to use _rev as a versioning system. Reiterating: I think the clean solution is to remove the API for loading docs at a particular rev. Instead we allow only the loading of all conflicted revs (or of course the HEAD rev). I'll wait for people to say why this is a bad idea before I say why it's a good idea. Cheers, Chris -- Chris Anderson http://jchris.mfdz.com