Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.217.162 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=V0CihcPG0ttAPzCXRD3GBGKsZYMIu3xKFHwl31sm+o065HXIM4+m2HXz4T8gJtp4ju
         QDpnw8o0NzjGZ5Fhe3yvyFRYqNcGAvtRzi+2QQ4k8QkMPzgJcJGv63v0fz8UCb6s5VgV
         TqhVf3lnlndQwtXpjGCP07pBPXNvZuPkh6UAE=
MIME-Version: 1.0
In-Reply-To: <64a10fff0902231502n317456f8l80a9d19c36b704aa@mail.gmail.com>
References: <C65E3190-6D7D-4E23-A22E-05DC3C432E45@apache.org>
	 <22ECC59F-F646-4F07-9332-14371BA930BE@apache.org>
	 <FAA2B5B9-6396-4754-8318-08EFDDD0CE4B@dionne-associates.com>
	 <7060483c0902230711r3b02f2e5n9ebf5671aaa35c73@mail.gmail.com>
	 <6092422F-29C3-4E5D-B26C-9C0E8B2E9FB4@apache.org>
	 <64a10fff0902231502n317456f8l80a9d19c36b704aa@mail.gmail.com>
Date: Mon, 23 Feb 2009 18:23:53 -0500
Message-ID: <e2111bbb0902231523ma859116nd6d1aa3370a24134@mail.gmail.com>
Subject: Re: Fail on a simple case on replication
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Mon, Feb 23, 2009 at 6:02 PM, Dean Landolt <dean@deanlandolt.com> wrote:
> On Mon, Feb 23, 2009 at 10:30 AM, Jan Lehnardt <jan@apache.org> wrote:
>
>>
>> On 23 Feb 2009, at 16:11, Patrick Antivackis wrote:
>>
>>  For a reminder :
>>>
>>> revision  (n)
>>> 1. the act or process of revising,
>>> 2. a corrected or new version of a book, article, etc.
>>>
>>> For me this term is correct with the use in Couch
>>>
>>
>> Damien is not saying the usage is wrong in CouchDB, but people
>> associate more with "revision" than he'd like. Hence the proposal.
>>
>>
>>  I think a good explanation of what a compaction/replication are doing (ie
>>> removing  old rev, or replicating only current rev) is the right solution
>>> to
>>> this misunderstanding
>>>
>>
>> Can you suggest how we improve the wiki docs to satisfy this? In my
>> opinion, the docs are clear* and the term is overloaded and confusing.
>>
>> * http://wiki.apache.org/couchdb/Document_revisions has
>> "You cannot rely on document revisions for any other purpose
>> than concurrency control." in bold letters.
>>
>> I stated this in earlier discussions as well: Even if our documentation
>> were perfect, we don't control how people learn about CouchDB. We
>> only control the API and we should work hard to get it right.
>>
>> The way it stands now, a lot of people new to CouchDB get it wrong
>> because "revision" is a familiar term and they associate the behaviour
>> they associate with it to them. That's how humans learn. In this case
>> we make the learning hard.
>
>
> I couldn't agree more with this sentiment, but revision still strikes me as
> the right term. Perhaps the easiest way to fix this misconception is for
> there to actually be a way to keep old revisions around for good :)
>
> Would it be overly difficult to just add in the ability to keep a full rev
> history based on a config setting? The replication api would need to
> accommodate this, of course, and if the machine you're replicating from
> doesn't also keep old revisions around your SOL, but is there any other
> compelling reason to not offer this option? If it wouldn't complicate the
> code base, this seems like a helpful feature. Sure, it could be wasteful and
> should be off by default, but if your dataset is relatively small, this
> config flag would be pretty nice to have, and it could help clear up this
> confusion.
>

I don't (yet) have a very through knowledge of everything that happens
inside the db files, but from the little I do know changing the
operation seems like it'd be a tall order. Then again, I could be
wrong.

Also, my suggestion for renaming would be _lock.

HTH,
Paul Davis