25 Jul
2007
25 Jul
'07
4:38 p.m.
On Jul 25, 2007, at 4:25 PM, Artem Melentyev wrote:
Hi.
Ludovic Dubost wrote:
That is looking complex to me. I'd rather we implement a solution
that works without having to configure anything. That said I haven't
followed the discussion... Will catch up later.
-Vincent
I think we don't need history to be
compatible but we need a
migration path (a script to migrate the previous history).
I'm more and more thinking we should get rid of RCS as the
versioning system. In the P2P XWiki Project we have been talking
about implementing a "XWiki Patch" notion because we need it to
send it over the P2P network for replication. This "XWiki Patch"
could be the new minimal set of information we need for a version.
Now I think we also need a table of versions to hold some key meta
data directly available (not as diff) so that we can display it in
the history page quickly. We could decide to store either the
patch (less space) or the full XML version in this table (more
space but very safe and faster).
....
We could decide to store the full document every 10 versions and
store only the patch (RCS or new XWiki Patch) for each
intermediary version..
This would mean that to retrieve any version you need one full
version + 10 nodes..
What if we allow to configure (via xwiki.cfg. parameter
"xwiki.store.rcs.fullpernodes" for example) per how many nodes to
store full version?
If we choose per 1 node, xwiki will store full document for each
version.
If we choose per 0 node, xwiki will store only diffs.
This parameter will be 50 by default.
I think it is best solution of choose full vs diff and
it is not to
hard to implement. I'm implementing it now.
WDYT?