couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: Fail on a simple case on replication
Date Wed, 25 Feb 2009 05:07:53 GMT

On 25/02/2009, at 2:55 PM, Chris Anderson wrote:

> Reiterating: I think the clean solution is to remove the API for
> loading docs at a particular rev. Instead we allow only the loading of
> all conflicted revs (or of course the HEAD rev). I'll wait for people
> to say why this is a bad idea before I say why it's a good idea.

Also, without access to the common ancestor of a document and it's  
conflicts, you can't use three way merging as a conflict resolution  
strategy, because you only have instantaneous state. Or am I wrong to  
think this is possible in any case? Can you chase down a conflict's  
ancestry to find the divergent point?

However, both this point and my previous point are moot, because the  
replication model means that access to arbitrary previous revisions is  
only likely on the node where the revisions were written. Access to  
only the head and it's conflicts (and the conflict chain I presume) is  
all that is consistent with replication.

I'm wondering therefore if lazy updating externals that respect the  
request's update_seq are not in fact possible given replication?

Antony Blakey
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Borrow money from pessimists - they don't expect it back.
   -- Steven Wright

View raw message