25 Jul
2007
25 Jul
'07
11 a.m.
On Jul 24, 2007, at 11:30 PM, Ludovic Dubost wrote:
Artem Melentyev a écrit :
I also sent an email about having a diff object inside XWikiDocument
to know what changes were brought to a document. I'm definitely +1
for doing this. It's quite easy to do at the level of XWikiDocument
because then you can set the state of this diff object at the time
when the different methods of XWikiDocument are called. The only
"hard" part would be to break down a content change into several
patches but this can be done as we're now storing the original
document into the XWikiDocument class.
[snip]
-Vincent
Hi.
I implement some of this proposal in XWIKI-1459.
And I want to discuss some problems about it.
1) Separate diffs.
Sergiu propose to store document archive in separate fields
(content, metadata, objects, attachments) instead of one field.
But it is incompatible with old document history system (If we
know one diff for all, it is impossible to understand what field
has changed)
If we will implement this, we will lose old document history or
we will be needed to write complicated migrator from old history
to new.
Need we save compatibility of 1.0 document history in xwiki-1.1 ?
I think separate diff will bring more complex than profit and no
needed at least in xwiki-platform-1.1.
WDYT?
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.