>
> This could also be implemented using a combination of raw inline and meta
> to change the title (add a "redirected from etc." page. This could be done
-> with a plugin. A redirect page would be [[redirect page="newpage"]].
+> with a plugin. A redirect page would be [[!redirect page="newpage"]].
> But then if you click "edit" on this redirect page, you won't be able
> to edit the new page, only the call to redirect.
> --Ethan
-----
-[[tag patch]]
+[[!tag patch]]
This is my second cut at a feature like that requested here.
It can also be found [here](http://ikidev.betacantrips.com/patches/move.patch).
would be possible to code up a different rename button that doesn't do
that, and use it elsewhere.)
+Hmm, unless it saves the edit state and reloads it later, while using a separate
+form. Which seems to solve other problems, so I think is the way to go.
+
## SubPages
When renaming `foo`, it probably makes sense to also rename
## RCS
-Two new optional functions are added to the RCS interface:
-
-* `rcs_delete(file, message, rcstoken, user, ipaddr)`
-* `rcs_rename(old, new, message, rcstoken, user, ipaddr)`
-
-The page move/rename code will check if these are not available, and error
-out.
+Two new functions are added to the RCS interface:
-Similar to `rcs_commit` both of these take a rcstoken, which is generated
-by an earlier `rcs_prepedit`.
+* `rcs_remove(file)`
+* `rcs_rename(old, new)`
## conflicts
* Alice clicks "delete" button for a page; Bob makes a modification;
Alice confirms deletion. Ideally in this case, Alice should get an error
message that there's a conflict.
+ Update: In my current code, alice's deletion will fail if the file was
+ moved or deleted in the meantime; if the file was modified since alice
+ clicked on the delete button, the modifications will be deleted too. I
+ think this is acceptable.
* Alice opens edit UI for a page; Bob makes a modification; Alice
clicks delete button and confirms deletion. Again here, Alice should get
a conflict error. Note that this means that the rcstoken should be
recorded when the edit UI is first opened, not when the delete button is
hit.
+ Update: Again here, there's no conflict, but the delete succeeds. Again,
+ basically acceptible.
* Alice and Bob both try to delete a page at the same time. It's fine for
the second one to get a message that it no longer exists. Or just to
silently fail to delete the deleted page..
+ Update: It will display an error to the second one that the page doesn't
+ exist.
* Alice deletes a page; Bob had edit window open for it, and saves
it afterwards. I think that Bob should win in this case; Alice can always
notice the page has been added back, and delete it again.
+ Update: Bob wins.
* Alice clicks "rename" button for a page; Bob makes a modification;
Alice confirms rename. This case seems easy, it should just rename the
modified page.
* Alice renames (or deletes) a page. In the meantime, Bob is uploading an
attachment to it, and finishes after the rename finishes. Is it
acceptible for the attachment to be saved under the old name?
+* Alice starts creating a new page. In the meantime, Bob renames a
+ different page to that name. Alice should get an error message when
+ committing; and it should have conflict markers. Ie, this should work the
+ same as if Bob had edited the new page at the same time as Alice did.
+* Bob starts renaming a page. In the meantime, Alice creates a new page
+ with the name he's renaming it to. Here Bob should get a error message
+ that he can't rename the page to an existing name. (A conflict resolution
+ edit would also be ok.)