h.b.furuseth@usit.uio.no wrote:

Pierangelo Masarati writes:

...

I think ITS#5326 is related. Namely, write operations (add, rename) should always rebuild the (new)DN hierarchically from the tree.

I'm not sure what exactly the problem is, if any:-) Syncrepl itself needs to handle databases that are not that nice: We can't require that of back-perl, nor back-ldap which accesses a non-OpenLDAP server (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl is an RFC (4533) so it should handle non-OpenLDAP peers.

Syncrepl of course *handles* all of those cases. The only issue here is that our tests expect the results to be in a specific order, which is obviously an invalid requirement in the grand scheme of things.

Still, if it keeps OpenLDAP-on-OpenLDAP clean, that's a plus. Unless we want back-ldif to be different just to test that syncrepl handles different backends. Might also make a test which replicates between different backends - e.g. $BACKEND and back-ldif.

The syncrepl rename-detection can be improved - we can compare the normalized parent DN, separately from the un-normalized RDN. This would eliminate a false detection of a move/rename solely due to superior RDNs being mismatched.