On Mon, Feb 23, 2009 at 6:02 PM, Dean Landolt <[email protected]> wrote: > On Mon, Feb 23, 2009 at 10:30 AM, Jan Lehnardt <[email protected]> wrote: > >> >> On 23 Feb 2009, at 16:11, Patrick Antivackis wrote: >> >> For a reminder : >>> >>> revision (n) >>> 1. the act or process of revising, >>> 2. a corrected or new version of a book, article, etc. >>> >>> For me this term is correct with the use in Couch >>> >> >> Damien is not saying the usage is wrong in CouchDB, but people >> associate more with "revision" than he'd like. Hence the proposal. >> >> >> I think a good explanation of what a compaction/replication are doing (ie >>> removing old rev, or replicating only current rev) is the right solution >>> to >>> this misunderstanding >>> >> >> Can you suggest how we improve the wiki docs to satisfy this? In my >> opinion, the docs are clear* and the term is overloaded and confusing. >> >> * http://wiki.apache.org/couchdb/Document_revisions has >> "You cannot rely on document revisions for any other purpose >> than concurrency control." in bold letters. >> >> I stated this in earlier discussions as well: Even if our documentation >> were perfect, we don't control how people learn about CouchDB. We >> only control the API and we should work hard to get it right. >> >> The way it stands now, a lot of people new to CouchDB get it wrong >> because "revision" is a familiar term and they associate the behaviour >> they associate with it to them. That's how humans learn. In this case >> we make the learning hard. > > > I couldn't agree more with this sentiment, but revision still strikes me as > the right term. Perhaps the easiest way to fix this misconception is for > there to actually be a way to keep old revisions around for good :) > > Would it be overly difficult to just add in the ability to keep a full rev > history based on a config setting? The replication api would need to > accommodate this, of course, and if the machine you're replicating from > doesn't also keep old revisions around your SOL, but is there any other > compelling reason to not offer this option? If it wouldn't complicate the > code base, this seems like a helpful feature. Sure, it could be wasteful and > should be off by default, but if your dataset is relatively small, this > config flag would be pretty nice to have, and it could help clear up this > confusion. >
I don't (yet) have a very through knowledge of everything that happens inside the db files, but from the little I do know changing the operation seems like it'd be a tall order. Then again, I could be wrong. Also, my suggestion for renaming would be _lock. HTH, Paul Davis
