couchDB-replication

This is document for CouchDB: http://docs.couchdb.org/en/2.2.0/intro/index.html
I just give some my ideas about replication.
I`m not good at English,but I’m practicing it, and this is my first post.
1.At the beginning of replication, Replicator verify peers, meaning that source and target both exist, if target does not, create it or not, choosing later one means you abort this process.
2.After verifying peers, Replicator retrieves basic information both from source and target, the information that Replicator needs the update_seq field which is used to define a temporary upper bound for Changes Feed listening and statistic calculating to show proper progress.
before we talk about last step, we need to know some tips:
(1)Sequence ID: you may see this keyword in introduction which methons this used for document index and storing the latest revision for a document, you may keep cautious attitude there may be different syntax just with the same name, at first ,I’m also confused by these conception, but you will find it out with a picture I provide.
(2)Changes Feed: a steam of events for changes, each event recorded meaning that a document get a new revision, and you can see, every event leads to a new sequence ID. if you still confuse about it, say what this conception have effect on, ok, lets go on.
(3)Checkpoint: which hold the sequence ID, it means you could get a point in Changes Feed as a startup for Replication.
Getting into details with the picture:
3.As you can see, we find peers common ancestry which means we get a checkpoint as a startup in Changes Feed, in such situation, we can easy find out that both source and target have a common replication history, in other word, we need not to replicate source to target with get changes at the beginning of changes feed, it make sense in fact and ensure high efficiency. You may wondering where the checkpoint comes from, going on and you will get it. 4.After getting a checkpoint, Replicator will listening to Changes Feed using checkpoint as a startup, replicator will read batch of changes in order it can be optimal use of resources. In Ordering to locate changes, replicator forms a JSON mapping object for Document ID and related leaf Revisions and sent results to target. In the response the Replicator receives a Document ID – Revisions mapping, but only for Revisions that do not exist in Target and are required to be transferred from Source. 5.When there are no more changes left to process and no more Documents left to replicate, the Replicator finishes the Replication process. If Replication wasn’t Continuous, the Replicator MAY return a response to client with statistics about the process. 6.If there any difference found in step 4, replicator will fetch documents and upload these to target. reading document about this to find more details.and then go to step 4. Since batches of changes were uploaded and committed successfully, replicator will update replication log both on source and target which hold the checkpoint, you can see checkpoint is recorded and it can be sued for next replication or replication recovery. With this posts hope you can never be confused by sequence ID checkpoint or replication log anymore.