>From this wiki document http://wiki.apache.org/couchdb/How_to_design_for_replication, Could you help me understand the approach mentioned in the approach 4: Keep historic versions explicitly,
"You can keep a pointer to the 'most current' revision, and each revision can point to its predecessor. On replication, merging can take place by diffing each of the previous versions (in effect synthesising the command logs) back to a common ancestor. " I'm wondering whether or not the replication here implies a couchdb replication with /_replicate or something else that db's application has to implement itself, if it is the former, how could we use merging to apply these explicit historic changes if different changes logs are happening both on the source and target db? I think it is still confused to me how this approach can really resolve the conflicted bookmark changes example in this wiki document automated after replication. -- Pan
