So do you think maybe deleting the entire CBLDocument and re-creating it might be a workaround for this problem? I still don't know why my 1- revision isn't getting deleted when I tell it to. Could it be that the new revision has such a large number? I mean, that it's not just one digit above the conflicted revision? I did let this process run for quite a while and that's why it's up over 4000- for the prefix of the revision ID.
Thanks, Brendan On Thursday, April 14, 2016 at 5:36:57 PM UTC-6, Jens Alfke wrote: > > > On Apr 14, 2016, at 1:55 PM, Brendan Duddridge <[email protected] > <javascript:>> wrote: > > Sorry, I meant to say "the new revision is getting its "isDeletion" flag > set to YES". > Maybe that's the problem? But I can't set the isDeletion flag unless I > create a new revision it seems. So that 1-409 is never going away and I > just keep creating new revisions over and over. > > > 1-409 doesn’t go away but it acquires a child, 2-xxx, which is marked as a > deletion. That means 1-409 is no longer a leaf, and 2-xxx is a leaf but > it’s deleted so it doesn’t count as part of a conflict. The result should > be no conflict. > > It sounds like the update of 1-409 isn’t taking effect somehow … weird. > > If you turn on logging for ‘CBLDatabase’ (or just ‘Database’, on the > master branch) you'll get logs for newly created revisions. That might help > figure out what’s going on. > > —Jens > -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/5e78fc32-1a9b-4d57-a92e-76738f573a62%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
