incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gaoyong pan <>
Subject design for replication
Date Mon, 22 Aug 2011 13:09:28 GMT
>From this wiki document, 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


View raw message