| CommunityTechBot updated the task description. (Show Details) |
CHANGES TO TASK DESCRIPTION
26570726f6475636520796f757220627567207573696e67206120726563656e742076657273696f6e206f662074686520736f6674776172652c20746f2068652077696b6920636f6e74656e74206c616e67756167652e0a0a5468616e6b20796f752e0a546167730a436865636b557365720ad70a436f6e6e65637465642d4f70656e2d48657269746167652d42617463682d75706c6f61647320285241c42d4b4d425f315f323031372d3032290ad70a54616d696c2d53697465730ad70a47616d6570726573730ad70a48617368746167730ad70a4a4144450ad70a4b6172746f456469746f720ad70a4c616e67756167652d323031382d4170722d4a756e650ad70a4e65772d456469746f722d457870657269656e6365730ad70a4d61696c0ad70a5443422d5465616d0ad70a53756273637269626572730a4465736372697074696f6e20507265766965770a436f6e74656e77a6f6e652073657474696e6720696e20796f75722070726f66696c652c20636c69636b20746f207265636f6e63696c652eThere is considerable confusion about what "parent revision" and "base revision" means in EditPage, WikiPage, and PageUpdater.
Status Quo
----------------
EditPage:
* editRevId and getBaseRevision() return the latest current revision as known to the client. This can be used to detect edit conflicts.
* oldId is the revision the edit was based on. When editing based on an old revision, it's the old revision's ID.
* parentRevId and getParentRevId() - The documentation says //The "parent" revision is the ancestor that should be recorded in this page's revision history. It is either the revision ID of the in-memory article content, or in the case of a 3-way merge in order to rebase across a recoverable edit conflict, the ID of the newer revision to which we have rebased this page.// However, this value does not to be recorded or in fact be used for anything at all. The semantics as described matches the rev_parent_id, but there is no need for EditPage to track this or set it explicitly. WikiPage (resp PageUpdater) just do this automatically.
* A CAS check is performed based on rev_id, ensuring the that current revision did not change after it was compared against editRevId to detect an edit conflict.
* see also {T58849} for how editRevId and parentRevId where introduced.
WikiPage:
* $baseRevId of doEditContent: The revision ID this edit reverts to, if any. Not stored, but passed to some hooks. Doesn't seems to be used for anything by core, but some extensions, like TimedMediaHandler, use it to detect reverts.
* rev_parent_id field: The ID of the revision that was current immediately before an edit. Used to display size differences in the page history (compare T193690)
NewRevisionFromEditComplete hook:
* $baseID: this hook parameter contains the value of $baseRevId from WikiPage::doEditContent. It's also set to the previous revision ID by MovePage. So the itnended semantics is "ID of an earlier revision that is restored or repeated by the edit".
PageUpdater:
* parent revision: the revision that is current before the edit is performed. Used for CAS checks.
* baseRevisionId: the latest current revision as known to the client. This can be used to detect edit conflicts. However, it is currently called set by doEditContent() with WikiPage's semantics in mind, causing confusion. Should probably be renamed to revertsToRevisionId.
Proposed Solution
--------------------------
* Improve documentation (and field names?) in EditPage to avoid confusion with the concepts as used in WikiPage.
* Improve documentation and parameter name in WikiPage::doEditContent to specify semantics to by "ID of an earlier revision that is restored or repeated by the edit"".
* Change PageUpdater::hasEditConflict() to not be based on the revision provided by setBaseRevision, but take a parameter and check against that instead.
* Change name of PageUpdater::setBaseRevisionId() to setOriginalRevisionId().
* Remove parentRevId logic from EditPage. getParentRevId() could just always return the current revision, if needed for B/C. But it does not seem like anything calls this.
Status Quo
----------------
EditPage:
* editRevId and getBaseRevision() return the latest current revision as known to the client. This can be used to detect edit conflicts.
* oldId is the revision the edit was based on. When editing based on an old revision, it's the old revision's ID.
* parentRevId and getParentRevId() - The documentation says //The "parent" revision is the ancestor that should be recorded in this page's revision history. It is either the revision ID of the in-memory article content, or in the case of a 3-way merge in order to rebase across a recoverable edit conflict, the ID of the newer revision to which we have rebased this page.// However, this value does not to be recorded or in fact be used for anything at all. The semantics as described matches the rev_parent_id, but there is no need for EditPage to track this or set it explicitly. WikiPage (resp PageUpdater) just do this automatically.
* A CAS check is performed based on rev_id, ensuring the that current revision did not change after it was compared against editRevId to detect an edit conflict.
* see also {T58849} for how editRevId and parentRevId where introduced.
WikiPage:
* $baseRevId of doEditContent: The revision ID this edit reverts to, if any. Not stored, but passed to some hooks. Doesn't seems to be used for anything by core, but some extensions, like TimedMediaHandler, use it to detect reverts.
* rev_parent_id field: The ID of the revision that was current immediately before an edit. Used to display size differences in the page history (compare T193690)
NewRevisionFromEditComplete hook:
* $baseID: this hook parameter contains the value of $baseRevId from WikiPage::doEditContent. It's also set to the previous revision ID by MovePage. So the itnended semantics is "ID of an earlier revision that is restored or repeated by the edit".
PageUpdater:
* parent revision: the revision that is current before the edit is performed. Used for CAS checks.
* baseRevisionId: the latest current revision as known to the client. This can be used to detect edit conflicts. However, it is currently called set by doEditContent() with WikiPage's semantics in mind, causing confusion. Should probably be renamed to revertsToRevisionId.
Proposed Solution
--------------------------
* Improve documentation (and field names?) in EditPage to avoid confusion with the concepts as used in WikiPage.
* Improve documentation and parameter name in WikiPage::doEditContent to specify semantics to by "ID of an earlier revision that is restored or repeated by the edit"".
* Change PageUpdater::hasEditConflict() to not be based on the revision provided by setBaseRevision, but take a parameter and check against that instead.
* Change name of PageUpdater::setBaseRevisionId() to setOriginalRevisionId().
* Remove parentRevId logic from EditPage. getParentRevId() could just always return the current revision, if needed for B/C. But it does not seem like anything calls this.
TASK DETAIL
EMAIL PREFERENCES
To: CommunityTechBot
Cc: pmiazga, Tgr, GoranSMilovanovic, Anomie, CCicalese_WMF, daniel, AndyTan, Gaboe420, Zylc, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, 1978Gage2001, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, SandraF_WMF, Bsandipan, Lordiis, herron, Adik2382, Chicocvenancio, alanajjar, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tbscho, Tramullas, Acer, LawExplorer, Lea_WMDE, Mattias_Ostmar-WMSE, Lewizho99, JJMC89, Maathavan, Jseddon, Agabi10, Ryuch, Mkdw, RuyP, JEumerus, Trizek-WMF, Susannaanas, KasiaWMDE, 0x010C, srodlund, Luke081515, grin, Bsadowski1, Aschroet, mys_721tx, Fjalapeno, Jane023, Wikidata-bugs, Snowolf, Base, matthiasmullie, aude, Huji, Gryllida, jayvdb, Ricordisamoa, Tobi_WMDE_SW, Lydia_Pintscher, Fabrice_Florin, Raymond, revi, scfc, He7d3r, Romaine, Steinsplitter, Mbch331, Jay8g, Ltrlg, Glaisher, Krenair, chasemp
Cc: pmiazga, Tgr, GoranSMilovanovic, Anomie, CCicalese_WMF, daniel, AndyTan, Gaboe420, Zylc, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, 1978Gage2001, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, SandraF_WMF, Bsandipan, Lordiis, herron, Adik2382, Chicocvenancio, alanajjar, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tbscho, Tramullas, Acer, LawExplorer, Lea_WMDE, Mattias_Ostmar-WMSE, Lewizho99, JJMC89, Maathavan, Jseddon, Agabi10, Ryuch, Mkdw, RuyP, JEumerus, Trizek-WMF, Susannaanas, KasiaWMDE, 0x010C, srodlund, Luke081515, grin, Bsadowski1, Aschroet, mys_721tx, Fjalapeno, Jane023, Wikidata-bugs, Snowolf, Base, matthiasmullie, aude, Huji, Gryllida, jayvdb, Ricordisamoa, Tobi_WMDE_SW, Lydia_Pintscher, Fabrice_Florin, Raymond, revi, scfc, He7d3r, Romaine, Steinsplitter, Mbch331, Jay8g, Ltrlg, Glaisher, Krenair, chasemp
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
