On Sun, Feb 8, 2009 at 6:07 AM, Patrick Antivackis <[email protected]> wrote: > 2009/2/8 Damien Katz <[email protected]> > >> 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
