rowan.collins wrote:

I don't really see the need for this; as far as I know, old revisions are
*never* deleted automatically in MediaWiki, and it is perfectly reasonable for
manual deletions to prevent diffs being made against the deleted revisions
(indeed, it would be something of a security glitch if it didn't, since it would
allow any user to view deleted pages, which are normally considered restricted
data).

So all that is actually needed for an lvr-enabled watchlist (which is bug 536)
is revision IDs that are guaranteed to last; the only currently identified
impediments are therefore bug 181 (current revisions do not have a lasting ID in
current DB schema), and bug 603 (old_id not preserved across delete-undelete
cycle).

Unless I'm missing something, such as plans to introduce automatic pruning of
old revisions, I suggest closing this as invalid, or as a duplicate of bug 536.
If there are plans for pruning, perhaps this could be rephrased as a blocker for
that - i.e. if you are developing a pruning system, you need to mark lv
revisions with a do_not_prune flag.

(In reply to comment #1)

I don't really see the need for this; as far as I know, old revisions are
*never* deleted automatically in MediaWiki

I am not sure, whether you are right. How can one get to older revisions of a
page, let's say (worst case), to the initial version ? This appears to be
limited to a certain maximum "go-back" number (say, 500 as a maximum). When I
use page history, I see that I can have 500 at maximum.

But I see, what you mean. And if you are right, that currently all revision can
be retrieved, than only the "keep permanent old_id" problem as in
http://bugzilla.wikipedia.org/show_bug.cgi?id=603 (delete/undelete cycle does
not preserve old_id) need to be solved.

This weekend, I'll have a look to the 1.3.7 and CVS code, if everything fits
together. Thank you you for your valuable comments !
Than I can closed this bugzilla and track only the other
http://bugzilla.wikipedia.org/show_bug.cgi?id=536 . Provisionally, as it looks
now, this 804 depends at least on 536, so I decided to set this dependency flag now.

Tom

Dear Brion,

instead of so ultra-quickly invalidating this bug without any comment, which
could be regarded as unfriendly, please could you as the master brain please
indicate and answer the herein-stated question:

whether really ALL OLD VERSIONS are kept ?

I am not sure. If, and only if really all old versions are kept, then this 804
is a 100% duplicate of bugzilla536 and can be deleted.

We mini-developers cannot overlook all brion-vibber-features of MediaWiki and I
would kindly inspire you to give understandable explanations - from which
certainly many mini-developers can learn, don't you think so ? I guess, that
anyone admires you and the co-workers and your admirable results, as I do, but
the documentation of the MediaWiki code is something, which leaves sometimes
doubts about its meaning and mechanisms, at least for me.

Tom

Yes, every revision is kept in the old table.

(In reply to comment #4)

Yes, every revision is kept in the old table.

Can you then please program (a.s.a.p.) a quick ad-hoc fix to the
http://bugzilla.wikipedia.org/show_bug.cgi?id=603 (delete/undelete cycle doesn
not prevserve old_id) problem ?

Then everyone would be happy:

• The Enotif patch can permanently point to a certain revision ("lvr") of a page
• As stated elsewhere, the Enotif patch will very soon display the requested

marker (on the "lvr" revision) - regardless whether the user actually enabled or
disabled to receive mails (I hope, that this is clear: every user can define, if
he/she wants to receive such MAILS. The "lvr" (or updated) marker is shown
independently from sending the mail)

• Several bugzillas can be closed, when I come up with the "lvr" marker as a

by-product of Enotif .

I guess, that closing this bugzilla is fine now, as the question a) is dealt
with in bugzilla603 (old_id) and question b) is answered now by Brion (yes, all
revisions are kept).

I am happy now, really.

So to summarise:
Can you, Brion, program or propose a QUICK solution to the
http://bugzilla.wikipedia.org/show_bug.cgi?id=603 problem ?

We need permanent IDs. What's about the usage of md5() in this context, perhaps
this leads to a solution: use md5(namespace:page_title:revision-id) as unique
number ? I have made excellent experiences with using md5() in several of my
other programs and I also know the md5() collision paper
http://eprint.iacr.org/2004/199/ , but this discovery shouldn't be a problem for
us. May I say "us" now ?)

Tom

rowan.collins wrote:

Just thought I'd clear up some misunderstandings:

(In reply to comment #5)

We need permanent IDs. What's about the usage of md5() in this context, perhaps
this leads to a solution: use md5(namespace:page_title:revision-id) as unique
number ?

There isn't really any need for a new ID: every revision currently has a unique
key in the "old" table of the database (which in a future version will also
include the current revision of each page). The only reason bug 603 exists is
that the "archive" table doesn't include this information, only the timestamp
and contents - so when a revision is undeleted, it is simply given a new,
unique, value as its old_id.

When I use page history, I see that I can have 500 at maximum.

I think you're misunderstanding the interface here: if you click the "next 50"
link enough times, you will simply continue through the history until you reach
the very first revision; the other links "(20 | 50 | 100 | 250 | 500)" are for
setting how many revisions to show *on each page*. So clicking the "500" will go
to a page with the first 500 revisions and - if there are more - a link labelled
"next 500". [e.g.
http://meta.wikimedia.org/w/wiki.phtml?title=Main+Page&action=history&limit=500&offset=0

• that page actually has somewhere over 1000 revisions stored]

[btw, were it valid this would have blocked bug 536, not been blocked by it]

(In reply to comment #6)

(In reply to comment #5)
There isn't really any need for a new ID: every revision currently has a unique
key in the "old" table of the database (which in a future version will also
include the current revision of each page). The only reason bug 603 exists is
that the "archive" table doesn't include this information, only the timestamp
and contents - so when a revision is undeleted, it is simply given a new,
unique, value as its old_id.

Thanky you Rowan for explaining. I also think, that you fully understand, what I
need, perhaps others, too:

a permanent revision number for a (namespace:page_title;revision), regardless
where the content acutally is saved in the database tables.

After an accidental or intendend deletion, this revision id must flagged as
("invisible, but in use") - thus not be given free ! - so that normal user
accesses to that specific revision are prohibited --- until possibly this page
revision is later undeleted by WikiAdmin. In this case, exactly that id needs to
be re-born again.

Can someone program this for the next release ? It would close many bugzillas at
once ...

Anyway, thank you so much for explaining.
Tom
Berlin

P.S. Have you tried my Enotif patch, see
http://bugzilla.wikipedia.org/show_bug.cgi?id=454 ?