Hi,

(I have asked this at StackOverflow, but, unsurprisingly, the question didn't get much attention.)

I'm designing replication conflict handling for a system, and one of its assumptions is that deletion always takes precedence when resolving conflicts: a deleted documents stays deleted regardless of what edits it conflicts with, IDs are not reused.

The "official" way of resolving replication conflicts (read conflicting revisions, merge in the application code, delete unwanted revisions) is not applicable to deleted documents. If a document is edited on instance 1, and deleted on instance 2, after replication both instances get the revision from 1. Because only one leaf revision is alive, the document ends up "undeleted", and without conflicts. The other revision ends up in _deleted_conflicts field, instead of _conflicts, but I can't use _deleted_conflicts as a cue that a document was deleted, because it includes deleted revisions from resolving edit conflicts and documents that were deleted and then re-added, so it's too general and conflates several cases.

How can I get around this at the CouchDB level? Moving it up the application layer gets really hairy really quickly as now I have to have my custom "deleted" flag, rewrite my views, test more code and have extra batch jobs to clean up records marked for delete.

Regards,
Alex.