On 12/09/05, Netocrat <netocrat(a)dodo.com.au> wrote:
[snip]
The three main reasons to find an improvement to rcs
diffs were stated as:
* moved paragraphs
* reverted edits
* minor changes within a line
The 1st and 3rd could be handled by a customised diff format and the 2nd
could be handled by links in the database - have those possibilities been
considered and what pros/cons are there to this approach vs the current
compression scheme?
There was discussion about this when the new DB schema was created
(live in v1.5) - a "revision" is now stored as metadata, distinct from
the "text" it references, so you can have null revisions (appear in
the edit history but point at the same piece of text), and potentially
store reverts by pointing back at an earlier piece of text.
Seems to me, this would be trivial to implement (if it isn't already)
for the admin "rollback" button, pretty easy when people edit an out
of date revision (diff their edit against the version they're
editting; reuse the same text object if same), but slightly harder for
people manually reverting a small change as a normal edit (you'd need
to run diffs against the last few versions to see if any of them were
identical to the new one).
Of course, the same logic needed for the second and third cases would
be what allowed a diff-based system to pick a better version to diff
against rather than assuming the previous. (It could then ignore major
changes which were later reverted, even if the text was also changed
during the revert)
Not really.
Tagging of revisions is likely to happen soonish, branching
not so likely.
Being able to specify a particular revision in a link would be useful - I
presume that's why tagging is being considered.
You can already specify a particular revision numerically (as of 1.5;
before that, the current revision wasn't stored as a revision) -
indeed, there is now a "permanent link" in the toolbox to bookmark the
current revision.
The point about tagging is for things like releasing "stable"
snapshots of a project - you need to have a database marker on the
"stable" revision of each page.
--
Rowan Collins BSc
[IMSoP]