Requests for comment/Nonlinear versioning
|Implementation status||not implemented|
This request for comment proposes a MediaWiki extension to allow branching histories for article content.
Overview[edit | edit source]
Please see the IdeaLab proposal for a human-readable explanation of this initiative.
Implementation[edit | edit source]
A very basic prototype, Extension:Nonlinear, can track branches and display them in the history log. There is no UI to create branches, yet.
Plan[edit | edit source]
- Gather requirements and community feedback, especially looking for help with the UI and finding the minimal useful scope for an initial release.
- Write an extension to create and manage branches
- Integrate with protection and antivandalism extensions
- Extend schema to provide enhanced metadata and multiple inheritance
UI changes[edit | edit source]
The edit page will always be available.
If the user does not have permission to edit the live version of a page, the "Save" button will change to "Submit for review".
A "Save draft" button may appear in the edit page. The effect would be to save the current text to a user sandbox page, where it will not appear in the site's "Recent changes". When editing is resumed and then completed, it can be saved under its original article name.
Schema changes[edit | edit source]
It has been pointed out that the current "revision" table already supports arbitrary directed graphs, so our extensions will simply provide extra information about these links. If the extension is disabled or uninstalled, the remaining links should not corrupt the database. Any revisions not appearing in the live article (trunk) should appear in the article's history page with a branch marker.
In later stages of implementation, we will need to improve the schema in order to support merging and other metadata.
Review and merge workflow[edit | edit source]
We'll have to enhance the review workflow in order to support more complex types of merging.
Considerations[edit | edit source]
Divergence[edit | edit source]
We should build a system which encourages frequent merge/split resolution. The possibility of parallel articles is interesting, but would be a usability disaster. Also, because merging patches in non-line-based documents is not a well-studied problem, and prose is very sensitive to context, the opportunity for merging recedes as branches diverge.
Branching model[edit | edit source]
There are many options here. I am prejudiced towards a system like Wikimedia's git/gerrit review, where changes are always based on the currently accepted revision, "master". This solves the problem in which vandalism and its rollback are leapfrogged over legitimate changes. A major drawback is that patches can get lost or ignored, and become stale relative to master, causing the divergence problem above.
Complexity[edit | edit source]
It's probably best if this feature is mostly transparent to editors and readers. Branching is the cause of much confusion in source control systems, and there is little agreement on the best practices, even for the most basic tasks like development and releases. Ideally, a branch is created by the backend whenever necessary (i.e., whenever the trunk does not track the change), according to predetermined logic.
Interwiki / Closed wikis[edit | edit source]
This concept could be used across wikis, if the schema supported it.
For example, I find a protected page on a wiki which does not have the nonlinear extension. I copy that page onto my home wiki, using a tool which preserves origin metadata. I can edit, and publish the altered page and diff for review, locally.
No common ancestor[edit | edit source]
If revision metadata is lost or damaged, it would still be nice to have some ability to reintegrate the lost changes. For example, a page is copied into a sandbox incorrectly, then edited. We should be able to diff any pair of articles, and merge on a per-chunk basis.
- Platonides, "Re: [Wikitech-l] Article revision numbers" Jul 16, 2012. (gmane)