couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Antivackis <patrick.antivac...@gmail.com>
Subject Re: proposed replication rev history changes
Date Sun, 08 Feb 2009 11:07:48 GMT
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.

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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message