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 patrick.antivackis@gmail.com
 designates 209.85.220.20 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;
        b=WDC8kZoB+fMbL3ef3o1+RI93nxE7pk4z0tbJkjsCYjo781o/66oQzN0LjRY96McDt+
         zqnkyX3LRvCR2t+aCHz/9tJD9tMjYlLyVW2M/y5P8RB9uLbazCGW/PG0WDlYP0Q0MPqY
         T++lanq/h8nlsQbCLFWRfZZAL+gUxsqhEmoSQ=
MIME-Version: 1.0
In-Reply-To: <e2111bbb0902080910k4fb05f0bq33ed8bbeb461873e@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>
	 <e2111bbb0902080810g472103e8ube9f53966299af89@mail.gmail.com>
	 <7060483c0902080850w126d4208yd50bb65921c9137d@mail.gmail.com>
	 <e2111bbb0902080910k4fb05f0bq33ed8bbeb461873e@mail.gmail.com>
Date: Sun, 8 Feb 2009 18:14:01 +0100
Message-ID: <7060483c0902080914w1eadaf12h8525e4af53c5aee9@mail.gmail.com>
Subject: Re: proposed replication rev history changes
From: Patrick Antivackis <patrick.antivackis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=001636c5b31a5b0e3e04626b619c

--001636c5b31a5b0e3e04626b619c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

And what today's revision system help in such a case ?


2009/2/8 Paul Davis <paul.joseph.davis@gmail.com>

> On Sun, Feb 8, 2009 at 11:50 AM, Patrick Antivackis
> <patrick.antivackis@gmail.com> wrote:
> > I'm not sure I understood what you asked.
> >
> > It would be a conflict of document, that would need either manual
> correction
> > or why not an automatic correction applying a move to one of the
> document,
> > but at least couch can tell for sure it was not the same document at the
> > origin.
> >
> > What I not understand is what today's revision system or proposed
> revision
> > system will bring more for this kind of conflict with two different
> > documents are created with same Id on two different nodes ? Except that
> with
> > the new revision proposal, you don't know for sure it was same or
> different
> > document at the origin if replications occurs after you trimmed the
> > reference to the first revision.
> >
>
> I'm saying that your suggestion to always retain the first revision is
> going to run into problems when a document is created on two machines
> and thus has to initial revisions. Or rather, it will run into the
> same problems as Damien's proposal yet have the added complexity that
> we now have the special cased 'first revisions' info.
>
> Unless of course I'm missing something else in the details.
>
> >
> >
> >
> > 2009/2/8 Paul Davis <paul.joseph.davis@gmail.com>
> >
> >> 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
> >>
> >
>

--001636c5b31a5b0e3e04626b619c--