If it is impossible to resolve the conflict without previous versions, then it would be forced to return undefined.
The problem of not having information about what changed is a big problem in couch even when the app is doing the conflict resolution. On Wed, Aug 31, 2011 at 12:09 PM, Jens Alfke <[email protected]> wrote: > > On Aug 31, 2011, at 11:58 AM, Mark Hahn wrote: > > It would have to be guaranteed to give the same results on all > servers. This is the same condition the current couch has. It would > effectively be replacing the current algorithm unless it returns > undefined. > > That would be tricky if it were trying to merge changed fields. Determining > whether a field changed relies on comparing its value to the previous > revision, but “previous revision” isn’t a well-defined concept in CouchDB*. > So if two nodes have differing sets of prior revisions, they might come to > different conclusions about which fields changed, resulting in different > merges. > > —Jens > > * Or that’s my impression; I might be wrong. My understanding is that, unlike > a VCS, CouchDB doesn’t store the parent revision ID in a document, so there’s > no explicit tree of revisions. And anyway there’s no guarantee that an > earlier revision still exists, since they all get removed during compaction. > Someone let me know if this is inaccurate. >
