Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.132.247 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=Hz2Wy/Dlo6MT96IarNg+r/1xkjqPVkOB9SCH1TrFxiO6x2uLaE/4VaHMYGd6s4h7vL
         6c3JQJDP4b/8FD/WOdLZZBgyzZpD3ozxfBK68G4PByzsenvEXyMPn3J8Y/RVQ4h2+Jui
         SW02hjnK5fhn9ISGqR8cMh8q6dncfOfW1oQZ4=
MIME-Version: 1.0
In-Reply-To: <7060483c0902080307y6169cc11n393df5be133d133f@mail.gmail.com>
References: <5B2D5ED2-6B85-41D7-BA78-3DD4BE7AFE13@apache.org>
	 <7060483c0902071559m1421b3bewb4bc6396124cb969@mail.gmail.com>
	 <8286B2B4-4D0F-47CD-8AA6-6CBC872C02CF@apache.org>
	 <7060483c0902080307y6169cc11n393df5be133d133f@mail.gmail.com>
Date: Sun, 8 Feb 2009 11:10:01 -0500
Message-ID: <e2111bbb0902080810g472103e8ube9f53966299af89@mail.gmail.com>
Subject: Re: proposed replication rev history changes
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 Sun, Feb 8, 2009 at 6:07 AM, Patrick Antivackis
<patrick.antivackis@gmail.com> wrote:
> 2009/2/8 Damien Katz <damien@apache.org>
>
>> You got everything right except this. It doesn't solve the problem, because
>> on another node, I could have a document that looked like ["1-foo" "2-bif"].
>> That is a real edit conflict that wouldn't be caught by what I think you are
>> proposing.
>>
>
> That's right,  there is a real edit conflict, but at least couchdb can
> detect it based on the first revision reference that is always kept.
> If you not keep the reference of the first revision you can arrive to :
> BaseA : ["1-foo"]
> BaseB : empty
> Replication :
> BaseA : ["1-foo"]
> BaseB : ["1-foo"]
> Life goes on :
> BaseA : ["1-foo" "2-bar" "3-baz" "4-biz"] but as it's trimmed to 3 you only
> keep ["2-bar" "3-baz" "4-biz"]
> BaseB : ["1-foo" "2-bad" "3-baf" "4-bif"] but as it's trimmed to 3 you only
> keep ["2-bad" "3-baf" "4-bif"]
> New replication :
> ????? same Id but no common revision, what we do ? And couch can not even
> help to say if it was same doc or not at the origin.
>

Patrick,

I'm pretty sure i see where you're coming from, but can you explain
what would happen if the same document ID were created on two servers?
Each server would have a different 'first rev' so who's first rev
would be carried on in the future?

> This is used during conflict detection to figure out if 2 tree fragments
>> overlap. We don't actually store a sequential number for each revision, we
>> store a revision tree of numbers, with the root of the tree being the offset
>> from 0 where it was trimmed (technically it's stemmed).
>>
>
> You are right, keep trace of the numbrer of the revision is indeed important
> especially when a same origin document in updated on different nodes.But
> couldn't it be replace bu a timestamp, this is sequential too and give even
> more information.
>
>
>> Sometimes people can deal with spurious conflicts. This gives you the
>> option. If you don't want spurious conflicts, don't use this feature.
>>
>> And if you want the same document to be editted over and over, 100s of
>> thousands of times, this is really the only option. The revision history
>> will get too big and slow down updates tremendously.
>>
>> Sure but  I would say it's different use cases. Record management for
> examples needs to keep track of changes during a period of time. And in all
> CMS/ECM i have worked on, clean up of version is done on time base more than
> on number of revision having occured.
>

HTH,
Paul Davis