I hear you, Sam. Dropping conflict resolution was a painful decision. What it came down to was that the API we had in 2.0 beta, which called an app handler function with the conflicting revisions and the common ancestor, would have been too difficult for a lot of developers. Resolving conflicts this way is hard, and it has the potential for mistakes that can cause infinite loops where different clients resolve the conflict differently, creating another conflict, ad infinitum.
The specific problem Couchbase has with difficult/dangerous APIs is that we make our money from support contracts. If something generates a large volume of support requests, it becomes a big pain point for our support engineers, and ends up costing us money. So we have an incentive not to release such APIs. Which is a good thing in the long run, but in this case it’s currently painful.
What we’re doing is listening to developers who need conflict resolution, identifying the specific things they’d need, and deciding on what sort of API to provide. We are leaning toward things like conflict-resistant data types (CRDTs) that allow conflict-resolution strategies to be specified declaratively, but we’re open to other ideas too.
I’m sorry about the current situation, especially for your product, but I’m looking forward to being able to fix it before long…
PS: I also hear what you’re saying about not being able to afford EE licenses. We’re funded by those licenses, but we’re also proud of being open source, and of the open-source community around mobile in particular.