I'm not sure this is fixable with the current architecture. The
problem are the rules used to determine the current winner are:
Is Not Deleted > has the most edits > highest revid
To force one document to be a winning conflict on another document
would require the second rule to be changed or gamed. Gaming, by
inserting a bunch of dummy revisions would cause you to either grow
you revision list or to lose earlier revisions, making spurious edits
conflict more likely. Changing the rules might work, but you have to
consider other usage scenarios.
While it is annoying behavior to have your conflict suddenly be the
loser, that can always happen in a multi-user situation no matter what
the rules are. If you try to special case it for one usage scenario,
you might negatively impact other equally valid usages. I've thought
before about have a plug-in to determine the conflict "winners", which
might be the way to go here.
-Damien
On May 22, 2009, at 10:46 AM, Paul Davis wrote:
Paul,
Yeah, definitely file a bug. If you can cook up some JavaScript to
show it, that'd be awesome too.
Paul
PS, I always feel a bit odd addressing emails to myself.
On Fri, May 22, 2009 at 5:41 AM, Paul Carey <[email protected]>
wrote:
Hi
I can reproduce the following behaviour on 0.9.
1. Save a doc with property x:1 (after saving, the revision = 1-r)
2. Save again with property x:2 (after saving the revision = 2-r)
3. Save via bulk_docs with all_or_nothing:true, revision:1-r, and x:3
4. Load the doc. Half the time x = 2, the other half, x = 3.
This seems wrong to me, I believe x should always be 2. Should I
file a bug?
Thanks
Paul
