couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Fauxton Tidings
Date Fri, 21 Jun 2013 12:16:50 GMT
On Jun 21, 2013, at 7:58 AM, Jan Lehnardt <> wrote:

>> Step two is build out a proper interface around the _replicator
>> database, allowing you to create new persistent replications,
>> introspect existing replications, look at historic replications, and
>> also to visually expose the powerful advanced options of the new
>> replicator allowing higher throughput replications.
>> What kinds of interfaces sounds useful for interacting with the
>> replicator database? What would you find useful for creating and
>> managing replications through Fauxton?
> While a bit oblique in implementation, I like the git “remote” concept
> and I think it makes sense in the CouchDB context. Whether a remote
> is another CouchDB installation and databases are “branches” (in git lingo)
> or whether a database is a remote is up to decision, but I’d like
> to be able to configure a set of remotes for my current server (manually
> and automatically) and then start/stop/schedule/observe replication
> between the local couch and a “remote”, or two “remotes”, or whatever
> else makes sense.

Co-opting the git parlance could work well.  For my money the right analogy is that a CouchDB
server is a remote and databases take the place of repos.  Branching happens at the granularity
of a document, not a database, and replication pushes all branches of all documents in the
database to the remote.

View raw message