Incremental versioning of documents

[Jibe]

I'm considering using RavenDB to store *complex* documents: docs with
lots of nested sub-categories of information (like a structured tree-
map of free text fields). Multiple users will be able to modify these
documents quite frequently. I would like to trace who changed what
over time and be able to display a simple history of changes: a list
of which free text was modified by whom and when. I don't want to show
the full the document at each version step, but want to pin-point what
particular field was changed at that time.

I don't know how the versioning bundle works under the hood. Is it
storing only the differences between 2 successive versions of a given
document (incremental versioning), or is it storing the full document
each time a new version is being created? For the latter, I'm worried
the size of my DB will increase exponentially over time and might
become slow to query.

Any advice and/or experience on how to best implement the above use
case?

[Oren Eini (Ayende Rahien)]

The versioning bundle store full docs

But note that versioned snapshots are skipped for indexing

[Chris Marisic]

In a very trivial prototype we used http://comparenetobjects.codeplex.com/ to diff raven version documents and it was just EZ-MODE.

[Oren Eini (Ayende Rahien)]

EZ-MODE ?

[Chris Marisic]

EZ, as in easy, mode. Probably mostly US colloquial gaming/tech reference in retrospect.

[Oren Eini (Ayende Rahien)]

Not that easy.

It is fairly simple to do a diff (well, not really, but we'll ignore that).

How do you do a merge? rollback? how do you look at the full docs 3 versions ago? How do you do that with a capped history?

At any rate, it is not really relevant, the versioning bundle keeps the whole document.

[Chris Marisic]

With that library it's very easy to create a visual display that shows the changes to the end user. The fact it stores the whole documents then pretty much becomes immaterial because that library makes it very easy to show the changes between the versions.

From everything i took from Jibe's comments those are all presentation concerns and not relevant to actual database concerns.