>I'm not sure I understand why full history is needed. All that seems necessary is to have the backend keep the deleted >entries around and just mark them as being deleted. They would only be needed for the LDAP sync operations and not >show up for standard searches.
It is more problematic with the scoped-out entries by modify operations.
It is not possible to detect which entries were in the previous search result
without the pre-modify contents of the modified entry. This also applies for modrdn.
When the syncrepl supports both the operating modes (log-based and state-based in other terms),
then the server will be able to switch between the two modes. On the other hand,
if the state-based mode ([add+present]) is not supported as is the case in the current LCUP proposal,
the only option when the history is not enough would be to resort to a full reload,
which is far more expensive than the state-based mode of operation.
Suppose you are using the syncrepl in its persist mode.
There will be one initial refresh operation which sends [add+presents].
Compared to slurpd, it seems more scalable than the initial
db transmission that is required when the replica went out of sync.