couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hood <>
Subject Re: Temporal data
Date Sun, 08 Mar 2009 18:18:33 GMT

On Sun, Mar 8, 2009 at 4:39 PM, Chris Anderson <> wrote:
> I probably should be more coy about this sort of thing on the user list. ;)

I know what you mean - it's always dangerous for a committer to talk
about prospective functionality :-)

> The functionality is not and never will be appropriate for building a
> version control system. This planned feature is merely meant to make
> the database file more resilient, and make it so that the hard drive
> head never has to seek for writes. A consequence of the fact that the
> file is never modified, only appended to, is that it contains a full
> history of all updates (until compaction).

I don't think I need (or want) a VCS on top of Couch. I'd like just to
be able to navigate directly back to a dated snapshot as opposed to
having to resolve a complete history chain.

> There are 2 reasons you can't use this in an application. One is that
> you're better off assuming your application can't control compaction.
> The second is that you have to think this way if you'll be dealing
> with replicated data. If you have edits on dbB and you replicate them
> to dbA, dbA only see the edits that dbB would still contain if it were
> replicated.

Do you mean to say that you would lose the ability to retrieve earlier
versions of an document that is no longer replicated?

> If you are building a versioning application, your application needs
> to do the versioning. The patterns for this are straightforward. I'm
> sure Jan will post a link to his wiki when it's ready.

Cool. I don't think that I need a full blown versioning system,
otherwise I would probably be better off using something like git or
hg. As indicated beforehand, the functionality I was looking at is
along the lines of zfs send/receive.


View raw message