updated CHANGELOG

CHANGELOG

@@ -79,6 +79,67 @@ v3.0.0 (XXXX-XX-XX)
 v2.8.2 (XXXX-XX-XX)
 -------------------
 
+* the continuous replication applier will now prevent the master's WAL logfiles
+  from being removed if they are still needed by the applier on the slave. This
+  should help slaves that suffered from masters garbage collection WAL logfiles
+  which would have been needed by the slave later.
+
+  The initial synchronization will block removal of still needed WAL logfiles
+  on the master for 5 minutes initially, and will extend this period when further
+  requests are made to the master. Initial synchronization hands over its handle
+  for blocking logfile removal to the continuous replication when started via
+  the *setupReplication* function. In this case, continuous replication will
+  extend the logfile removal blocking period for the required WAL logfiles when 
+  the slave makes additional requests.
+
+  All handles that block logfile removal will time out automatically after at
+  most 5 minutes should a master not be contacted by the slave anymore (e.g. in
+  case the slave's replication is turned off, the slaves loses the connection
+  to the master or the slave goes down).
+
+* added all-in-one function *setupReplication* to synchronize data from master 
+  to slave and start the continuous replication:
+
+      require("org/arangodb/replication").setupReplication(configuration);
+
+  The command will return when the initial synchronization is finished and the 
+  continuous replication has been started, or in case the initial synchronization 
+  has failed. 
+
+  If the initial synchronization is successful, the command will store the given 
+  configuration on the slave. It also configures the continuous replication to start 
+  automatically if the slave is restarted, i.e. *autoStart* is set to *true*.
+
+  If the command is run while the slave's replication applier is already running, 
+  it will first stop the running applier, drop its configuration and do a 
+  resynchronization of data with the master. It will then use the provided configration, 
+  overwriting any previously existing replication configuration on the slave.
+
+  The following example demonstrates how to use the command for setting up replication
+  for the *_system* database. Note that it should be run on the slave and not the
+  master:
+
+      db._useDatabase("_system");
+      require("org/arangodb/replication").setupReplication({
+        endpoint: "tcp://master.domain.org:8529",
+        username: "myuser",
+        password: "mypasswd",
+        verbose: false,
+        includeSystem: false,
+        incremental: true,
+        autoResync: true
+      });
+
+* the *sync* and *syncCollection* functions now always start the data synchronization
+  as an asynchronous server job. The call to *sync* or *syncCollection* will block
+  until synchronization is either complete or has failed with an error. The functions
+  will automatically poll the slave periodically for status updates.
+
+  The main benefit is that the connection to the slave does not need to stay open
+  permanently and is thus not affected by timeout issues. Additionally the caller does 
+  not need to query the synchronization status from the slave manually as this is
+  now performed automatically by these functions.
+
 * fixed undefined behavior when explaining some types of AQL traversals, fixed
   display of some types of traversals in AQL explain output
 

Documentation/Books/Users/Replication/ExampleSetup.mdpp

@@ -41,7 +41,7 @@ require("@arangodb/replication").setupReplication({
 ```
 
 The command will return when the initial synchronization is finished and the continuous replication
-is started, or in case the initial synchronization has failed. 
+has been started, or in case the initial synchronization has failed. 
 
 If the initial synchronization is successful, the command will store the given configuration on
 the slave. It also configures the continuous replication to start automatically if the slave is