Alternatively, if you judge that the chance of edit collisions is slim, you can adopt a less expensive "optimistic" scheme were the first edit saved wins. A hidden timestamp in the edit form is sufficient for this. If the timestamp doesn't match the page/node timestamp when a save is attempted, the save loses (becomes a merge attempt).

A data point:

I use an optimistic scheme in a Wiki clone. It gets far less traffic than Perlmonks, but it's often the case that there's a "working set" of a dozen active pages during the course of a day, and edit collisions are rare. Given how quickly people jump on new nodes here, that might not be the case here.

At most have a message saying that "so and so started editing this time X ago" and let the editor decide whether they want to proceed.

I agree. But since vroom asked, I assumed that he had a reason (such as wanting to implement automatic "undo").

If you add to the above scheme a simple atomic test at final commit time to see whether the node has be changed since the editting began (as discussed already), then the editor can be warned that they are about to overwrite someone else's work. At that point, they can open another window and view the other work and decide whether to commit their own changes or not (or to merge some of the other editor's changes, etc.).

        - tye (but my friends call me "Tye")

Would that message clear when the "other" editor stubmit's the edit? Also, 'x' becomes a variable timeout, right?

In an ideal world, the list of people editing a node (in the case of editors) or replying to a node (for everyone) would get cleared out after a pretty long time (like an hour), if the edit/reply is ever committed, or if the editor/replier hits "Cancel" (a new button whose sole purpose is to remove you from the list of editors/repliers for a node, just out of courtesy).

But a first stab at this could skip the last item in the list to save development time.

        - tye (but my friends call me "Tye")