It might be simpler to implement wiki item renaming as a "move wiki item from node A to node B" operation:
- Item B is created if it does not exist.
- Item B adds a Revision with A's content and with metadata that says "moved from A".
- Item A adds a Revision that sets content to zero-length and with metadata that says "moved to B".
In this way all History is stored per name, which I think suits a wiki just fine and is even an improvement, since now anytime any node had this name, we will see its history under that name, a name which presumably gave meaning to those Revisions which were known by that name. Also, this moves the whole problem of maintaining history out of the hotter code paths.
Displaying History can be handled in two ways:
- When viewing the history, the "moved from A" could be expressed as a wikilink to the history of B, and vice versa. I suggest this would be sufficient for most purposes.
- the History view could follow the "moved to" and "moved from" links to gather a chain of Revisions to display what we are currently used to seeing as History.
objections/arguments to explore
will this "mix up" histories of "different" items?
how would it affect "trashing"?
ThomasWaldmann:MattMaker: that'll potentially mix up histories of different items MattMaker:I argue that if so, it would mix them up in a way that was actually closer to the user's intent ThomasWaldmann:btw, we use rename for trashing, too MattMaker:what you are thinking of as an item, is an abstract entity that could still be reconstructed as a path that follows a series of nodes, perhaps by giving a node a globally unique "origin" at birth, and remains readonly, which would then follow any moves as a bit of metadata MattMaker:the problem is similar to threading email discussions MattMaker:(when does the subject change so much that it should not be thought of as a reply? this happens often.) MattMaker:I haven't looked at trashing yet, but various possible definitions of it could be expressed in the scheme I am suggesting MattMaker:the question of security is an interesting one too. MattMaker:it depends on what you intend to protect ThomasWaldmann:the question is why should make it so complicated and not use anon items with uuid MattMaker:I think this is actually orthogonal to the uuid question. ThomasWaldmann:rename = metadata "name" change in a new revision of an uuid item MattMaker:there are two things one might uniquely identify: a named node, and a sequence of revisions. each could have a UUID, or not, that would be an implementation detail the user doesn't see. MattMaker:possibly, rename = metadata "name" means that indexing a "name" has to follow the revision paths every time it is calculated MattMaker:so in a way, histories are actually getting less mixed up, in my suggestion ThomasWaldmann:can you put that on a wiki page (I am rather tired right now) MattMaker:As a scientist, I wish to attempt to disprove my hypothesis MattMaker:yes, good idea MattMaker:(complexity: having to implement searching on uuid *and* names *and* internal backend identifiers) MattMaker:(although maybe just the first two, depending on implementations)