diff options
| -rw-r--r-- | doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn | 5 | ||||
| -rw-r--r-- | doc/todo/web_reversion.mdwn | 56 |
2 files changed, 58 insertions, 3 deletions
diff --git a/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn index dc2b7ca4a..4998c1a75 100644 --- a/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn +++ b/doc/forum/how_do_I_revert_edits_in_the_web_mode__63__.mdwn @@ -36,6 +36,5 @@ Puzzled a bit :-/ --- -There is some work in progress on this by Peter Gammie. --[[Joey]] - -[[!template id=gitbranch branch=peteg/master author="[[peteg]]"]] +Perer Gammie and I are working on reversion over at [[todo/web_reversion]]. +--[[Joey]] diff --git a/doc/todo/web_reversion.mdwn b/doc/todo/web_reversion.mdwn new file mode 100644 index 000000000..50cb13fad --- /dev/null +++ b/doc/todo/web_reversion.mdwn @@ -0,0 +1,56 @@ +Goal: Web interface to allow reverting of changes. + +Interface: + +At least at first, it will be exposed via the recentchanges +page, with revert icons next to each change. We may want a dynamic +per-page interface that goes back more than 100 changes later. + +Limiting assumptions: + +* No support for resolving conflicts in reverts; such a revert would just + fail and not happen. +* No support for reset-to-this-point; initially the interface would only + revert a single commit, and if a bunch needed to go, the user would have + to drive that one at a time. + +Implementation plan: + +* `rcs_revert` hook that takes a revision to revert. +* CGI: `do=revert&rev=foo` +* recentchanges plugin adds above to recentchanges page +* prompt user to confirm (to avoid spiders doing reverts), + check that user is allowed to make the change, commit reversion, + and refresh site. + +Peter Gammie has done an initial implementation of the above. +[[!template id=gitbranch branch=peteg/master author="[[peteg]]"]] + +> Review: --[[Joey]] +> +> The revert commit will not currently say what web user did the revert. +> This could be fixed by doing a --no-commit revert first and then using +> rcs_commit_staged. +> +> So I see one thing I completly forgot about is `check_canedit`. Avoiding users +> using reverting to make changes they would normally not be allowed to do is +> tricky. I guess that a easy first pass would be to only let admins do it. +> That would be enough to get the feature out there.. +> +> I'm thinking about having a `rcs_preprevert`. It would take a rev and look +> at what changes reverting it would entail, and return the same data +> structure that `rcs_recieve` does. This could be done by using `git revert +> --no-commit`, and then examining the changes, and then `git reset` to drop +> them. +> +> Then the code that is currently in IkiWiki/Receive.pm, that calls +> `check_canedit` and `check_canremove` to test the change, can be +> straightforwardly refactored out, and used for checking reverts too. +> +> (The data from `rcs_preprevert` could also be used for a confirmation +> prompt -- it doesn't currently include enough info for diffs, but at +> least could have a list of changed files.) +> +> Note that it's possible for a git repo to have commits that modify wiki +> files in a subdir, and code files elsewhere. `rcs_preprevert` should +> detect changes outside the wiki dir, and fail, like `rcs_receive` does. |