From user-return-15680-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Apr 06 20:25:13 2011 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 81262 invoked from network); 6 Apr 2011 20:25:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Apr 2011 20:25:13 -0000 Received: (qmail 44626 invoked by uid 500); 6 Apr 2011 20:25:11 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 44583 invoked by uid 500); 6 Apr 2011 20:25:11 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 44575 invoked by uid 99); 6 Apr 2011 20:25:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Apr 2011 20:25:11 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=FREEMAIL_FROM,FS_REPLICA,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of email.workbench@gmail.com designates 209.85.161.52 as permitted sender) Received: from [209.85.161.52] (HELO mail-fx0-f52.google.com) (209.85.161.52) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Apr 2011 20:25:04 +0000 Received: by fxm6 with SMTP id 6so2167623fxm.11 for ; Wed, 06 Apr 2011 13:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0doSPtvD6ZeTPAM5KJfIUaTRW3qIXfmuU+m3+kHpnVs=; b=gAvBO5gmOdfjXAGsPpAB3VgM+++ExKrt+C6MNM3usi4FGE7CPzpappLriu0I6O68ig zl6aXJ9vkcWPhmGAuGqEXVdQze0+cIMMc2O7Yk3bdpHvOvcZPzC+EKmURzC76nYNkwTu WEoShKgBclII7epv6M0oFPZr29NsDYK5SuG5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=q6bbm8mtPZ9vlg6/K14Txxj2fGB9K+c3wkE9yRkSx9RW9Z4KQ7bUfhMM/nOL36wvT9 wHeYo6Hv5fas2ExJjPj8zKsBGQM8IFQnXK0nBi9pX1lu9bce/VvVQBnWRyLwzGlAHpiD e3yCjeOZtIdboCTDOjfubFjfhaDvNKNunDDWQ= MIME-Version: 1.0 Received: by 10.223.2.205 with SMTP id 13mr37868fak.138.1302121483824; Wed, 06 Apr 2011 13:24:43 -0700 (PDT) Sender: email.workbench@gmail.com Received: by 10.223.121.82 with HTTP; Wed, 6 Apr 2011 13:24:43 -0700 (PDT) In-Reply-To: <4D9CBEEB.3090102@facilityone.com> References: <4D9CBEEB.3090102@facilityone.com> Date: Wed, 6 Apr 2011 16:24:43 -0400 X-Google-Sender-Auth: fyOz2HibL1nSCqpcgPk-MEcMG5o Message-ID: Subject: Re: Peer-to-Peer Replication From: Zdravko Gligic To: Owen Marshall Cc: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org > *You* make the graph -- not CouchDB! Given a large number of peers, could this not be a daunting task - to ensure that everyone gets eventually updated in a relatively efficient and timely manner? > CouchDB will follow your instructions. No more or no less. Am I correct in my interpretation of documentation that regardless of the overall design, replication is always between 2 nodes - a source and a target? In other words there is no way to throw at CouchDB multile nodes as sources and/or destinations and it would magically keep them all updated. > CouchDB doesn't ensure that the latest revision wins -- you are expected > to resolve conflicts in a way that makes sense for your application. I understand this in context of revisions to a single document. However, I was more curious about how it internally determined which of 2 arbitrary peers had a more recent and up to date copy. Thanks again.