Gaming via dummy revisions is an interesting hack. In any case, this isn't an issue for me, just something I noticed when writing tests. Although I am keen on the general idea of plugins for conflict resolution.
I won't file a bug, but I will add some more notes to the wiki. Paul On Fri, May 22, 2009 at 9:08 PM, Damien Katz <[email protected]> wrote: > 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 >>> > >
