Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of 0x6e6562@gmail.com designates
 209.85.220.165 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:content-transfer-encoding;
        b=H+G0+I1tuZ8wTnbpMnXzM5r+HPw2nEaBtjb/NP5N/8IwFGyUksCA+oHIY7OU4JZVMp
         cSvRrUihpNkJ9+WzVyvDSBqfOpw84yqqapoVz3G5yF2MSdtHKTjHlz/TdT9PUWZFVbAm
         lZ7wkDhMW5KH4CJOFcXunFx2NNsMtKFNdvNlc=
MIME-Version: 1.0
In-Reply-To: <e282921e0903080939r7f7d59f2i7869f17ded1259ae@mail.gmail.com>
References: <269388e30903071822g783df2cr62a3746fe3a297a1@mail.gmail.com>
	 <e282921e0903071930j7e48e57ei8c861cb49ed27ef@mail.gmail.com>
	 <269388e30903080435j2a19c252yb0b0f79a27bbe065@mail.gmail.com>
	 <e282921e0903080939r7f7d59f2i7869f17ded1259ae@mail.gmail.com>
Date: Sun, 8 Mar 2009 18:18:33 +0000
Message-ID: <269388e30903081118g6eede43bsf739add97d24e7db@mail.gmail.com>
Subject: Re: Temporal data
From: Ben Hood <0x6e6562@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Chris,

On Sun, Mar 8, 2009 at 4:39 PM, Chris Anderson <jchris@apache.org> 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.

Ben