[GitHub] [couchdb] nickva commented on issue #4034: Revs_diff returns a long list of deleted possible_ancestors

[GitBox <gi...@apache.org>]

nickva commented on issue #4034:
URL: https://github.com/apache/couchdb/issues/4034#issuecomment-1134996907

   The response to `_revs_diff` will be empty if the revisions from the POST request are already on the server. If the revisions are not on the server it will return them.
   
   The possible ancestors are computed only if the are missing revisions, and it returns the leaf revisions from the documents on the server (deleted or regular) if their revision depth (their level in the revision tree) is less than *any* of the missing revision. So if the missing revisions are {5, "abc"}, {7, "def"}, and the leaf revisions from the doc on the server are {1, "xyz"}, {6, "klm"}, {10, "ghi"} then possible ancestors would be {1, "xyz"} and {6, "klm"}. 
   
   A large number of possible ancestor points to there being a a lot of conflicts in the revision tree. You could try purging all those revisions on the source and then on the target, but make sure to purge every conflicted revision. 
   
   If there a chance you use clustering on any of the endpoints where the _purge was run and some nodes at the time were disconnected, it maybe possible some purge requests haven't propagated to all the nodes. Make sure to enable  `[mem3] replicate_purges = true` as I think by default that option was left as false and so purge requests might not propagate to all the nodes when more nodes reconnect.
   
   Here is away to filter out conflicts using replication and VDUs https://blog.cloudant.com/2020/11/26/Repairing-a-Database-With-Conflicts.html
    


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@couchdb.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org