Chris, On Sun, Mar 8, 2009 at 4:39 PM, Chris Anderson <[email protected]> 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
