On Feb 2, 2010, at 2:48 PM, Randall Leeds wrote: > On Tue, Feb 2, 2010 at 11:39, Chris Anderson <jch...@apache.org> wrote: >> On Tue, Feb 2, 2010 at 11:25 AM, Randall Leeds <randall.le...@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.
Yes, that's the problem we'll need to solve if we're going to use UUIDs to fast-forward replication. Off the top of my head, one way to do that would be store a DB revid calculated in the same way as the document revids (and seed it with the UUID at the beginning). Then if you find an update_seq where the revision IDs match, you can start the replication from that point. There may be cheaper ways, though. Adam
