For my client’s use case we use unidirectional replication of documents from Sync Gateway 2.7 to Couchbase Lite 2.7 client devices. Clients do not modify documents. We don’t need or want to replicate revision history to clients, which we’ve found to significantly impact replication performance. Instead we just want a ‘server always wins’ approach to conflict resolution.
On Sync Gateway I’ve set allow_conflicts to false, and revs_limit to 1. As a result, I get CB Lite logs that are full of warnings about ‘Server sent no history with …’. I assume the lack of history is due to revs_limit being set to 1. However, in our case this is intentional. Either I’m accomplishing my goal of stripping out revision history in the wrong way, or this log entry should not be a warning, but just informational.
Do I have this wrong? If so, what is the correct way? Otherwise, can this message be reclassified as informational in the next release?
Setting revs_limit=1 when clients are not continuously connected may cause that type of behaviour. Clients that are offline while the server updates a document multiple times will not be able to identify that their revision is an ancestor of the one the server has sent, and will treat the incoming update as a potential conflict. It sounds like you’ve got conflict resolution in place to resolve that as ‘server wins’.
I would expect that there’s a tradeoff between the performance benefit achieved by reducing transport of revision history, and the performance overhead of this false positive conflict resolution. You might want to tune revs_limit upward accordingly, based on your expected client partition window (i.e. how many mutations you expect in an average partition window).
Sorry for responding to such an old topic, but I’m still getting these warnings with Couchbase Lite 2.8. I have allow_conflicts=false and revs_limit=1 in sync gateway, and a custom conflict resolver where remote always wins when replicating to Couchbase Lite. Is there a way to suppress this warning? Would I really get better performance with a higher revs_limit although I don’t need or want revision history?