Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.218.209 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=ebx1LJ3Ro3liyzQ/LBqA8cRy20GpI2CG0U8CqvDo+14D47L6S3RpgxJlL7ieNlSezo
         TNKit6yGIPcZj73f7aPTTKcd+KtYouDeBWbB9lV3ae6hPq+R5zbuiFyJdrd2EnNs5MR1
         aCUJt6WtwlZNgntVnT7zdFVV2PV0bHxTpyzC4=
MIME-Version: 1.0
In-Reply-To: <e282921e1002021139u660e81e2n77ee23b897aaad90@mail.gmail.com>
References: <cadf1c691002011058r1cf1fbfbk45a41db9ea3932f7@mail.gmail.com>
	 <e282921e1002012116p2228afdaj1e36939664244189@mail.gmail.com>
	 <55047b711002012202j1878120epfb6a34629fcb812b@mail.gmail.com>
	 <ec7a93a1002012355s7d6c06fbwca6e99718750243d@mail.gmail.com>
	 <ec7a93a1002020007t4fe00734g6b12faabf570e716@mail.gmail.com>
	 <ec7a93a1002021125j11a87224h4b98ac64066cc7d9@mail.gmail.com>
	 <e282921e1002021139u660e81e2n77ee23b897aaad90@mail.gmail.com>
Date: Tue, 2 Feb 2010 11:48:19 -0800
Message-ID: <ec7a93a1002021148u20751c9chd1aed06e95c05257@mail.gmail.com>
Subject: Re: associating UUIDs to DBs
From: Randall Leeds <randall.leeds@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 2, 2010 at 11:39, Chris Anderson <jchris@apache.org> wrote:
> On Tue, Feb 2, 2010 at 11:25 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
>> I'm not entirely happy with this patch and I'd like some help figuring
>> out what to do about it.
>>
>> I foresee problems when database files are copied or backed up on
>> disk. It's possible to end up with two couchdb instances hosting
>> databases with the same uuid. The problem is that the uuid is no
>> longer meaningful, as it doesn't do what it was intended to (uniquely
>> identify the database).
>>
>> Can anyone see a way around this?
>>
>
> I think we don't mind this. As I mentioned above, when we see that 2
> db files have the same uuid we can do a fast-forward replication by
> starting from the lower of the 2 dbs sequence #s for replication.
> (maybe... Adam, does this sound sane?)

If changes had been made to both dbs separately then the lower
sequence # might be beyond the sequence number at which the histories
diverged and the changes to the "younger" db would be lost.