To do list review: small typo quick fix.

diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf
index 3f7690499a35fe534c9f32c6bba70a7f2929e150..6c7eb6e62366c8a29c7e01d1bcdf5933e87d9823 100644 (file)
--- a/doc/guide/admin/replication.sdf
+++ b/doc/guide/admin/replication.sdf
@@ -544,15 +544,14 @@ H3: Delta-syncrepl replication
 
 OpenLDAP's syncrepl replication is an object-based replication mechanism. 
 When any attribute value in a replicated object is changed on the provider, 
-each consumer fetches and processes the complete changed object {B:both changed and unchanged attribute values}
- during replication. This works well, but has drawbacks in some situations. 
+each consumer fetches and processes the complete changed object {{B:both changed and unchanged attribute values}} during replication. This works well, but has drawbacks in some situations. 
 
 For example, suppose you have a database consisting of 100,000 objects of 1 KB 
 each. Further, suppose you routinely run a batch job to change the value of 
 a single two-byte attribute value that appears in each of the 100,000 objects 
 on the master. Not counting LDAP and TCP/IP protocol overhead, each time you 
-run this job each consumer will transfer and process {B:1 GB} of data to process 
-{B:200KB of changes! }
+run this job each consumer will transfer and process {{B:1 GB}} of data to process 
+{{B:200KB of changes!}}
 
 99.98% of the data that is transmitted and processed in a case like this will 
 be redundant, since it represents values that did not change. This is a waste