Discussing Advanced Wiki Operations

The Trac wiki currently lacks some advanced features you can find in more mature wikis, operations like rename, copy and merge.

This will summarize and expand the proposals found in #1106 and other places.

Operations

Rename

See WikiRename.

Copy

Mainly interesting if supporting batch copies, a.k.a. Subversion style branching.

Merge

Note that there are several kinds of merge.

The one which is directly in line with the advanced wiki rename and copy operations is the operation consisting of merging two pages into one. This can also be seen as renaming a page to an existing page, which is currently forbidden. That operation can be used to consolidate several small topics into one umbrella topic, or for merging two synonym pages into one, etc.

In any case, this would involve to solve the following issues:

• merge the two wiki texts (#152). The existing interface for this is rather minimal, it only shows the differences without the possibility to say which side(s) should be kept.
• bringing over the attachments. We should also take care of possible conflicts at that level. The attachment rename methods from WikiRename will also be relevant for this operation
• merge the two lines of history. Maybe simply concatenate the two lines?
  1. v1 page a
  2. v2 page a
  3. v3 page a
  4. v1 page b (merged in)
  5. v2 page b (merged in)
  6. v6 page a (with b merged in)
  The diff between 3. and 4. would be meaningless, but besides this, it should be enough.
• merge the potentially conflicting fields besides the wiki text. Fortunately there's only the read-only flag, shouldn't be that hard ;-) But well, there's #695, #3911.

The other kind of improved merge is simply the resolution of conflicts in case of concurrent edits (#152). An improved interface for this situation should actually also handle the different points listed above (except merging the two lines of history).

Note that this advanced conflict resolution method would also benefit to other kind of resources, in particular #7145 (not to mention the possibility to merge tickets, in case of duplicates for example - #3006).

User Interface

The advanced operations should not clutter the wiki page. Instead of Copy and Merge buttons coming in addition to the Rename one, maybe a single Advanced… button would be preferable. This could go to a single page containing the different forms, one for each advanced operation. Plugins could add their own advanced operation there.

Section Editing

Many wiki's allow you to edit paragraphs or sections (while leaving the rest of the page un-edited. For example:

• ​Edit Links in Wikipedia

See also #1024.

Better Hierarchy Navigation

• In 0.12 we introduced the wiki page name path trail, visible in the top left corner of the page, which makes it easy to quickly navigate to any ancestor (#8857). But it would be nice if this could be used to navigate to children and, perhaps, siblings.
  • if there are children, the path trail would end with a ... link, leading to a page list (URL could be /wikilist/<wikipath>). If Javascript is enabled, the link could be disabled and replaced by an action that would query that same list with an XHR and display a selection list (or a more elaborate form of menu; but a simple <select> would probably do).
  • the same could be done for siblings actually, by turning each '/' path separator into a similar link

Compare different Wiki pages

• I can see this useful for Trac itself, comparing 0.11 and 0.12 versions of a page.

Current wiki diff link is:

http://trac.edgewall.org/wiki/TracLinks?action=diff&version=76&old_version=75

Possible suggestion:

http://trac.edgewall.org/wiki/TracLinks?action=diff&version=76&old_page=wiki/0.11/TracLinks/&old_version=75

This would belong under 'Advanced Operations' I guess? Possibly, yes.

But along with the TracDev/Branches/WikiBlame idea (and even the copy operation), I can't help but note that this would come for free if we had #1132 support ;-) Now that we have MultipleRepositorySupport and "unlisted" repositories (hidden = true) for those who would prefer that ancillary repository to remain invisible, this is increasingly becoming a more realistic option.

(rblank) I agree with that. Even more, I would like to be able to have the source code, wiki and tickets in a single DVCS repository, so that I can take the whole thing on the road. Something along the lines of ​Fossil. I guess the most difficult part is creating a GUI for merging that is simple enough.

(cboos) See also related discussion in DistributedTrac and above, in #Merge.

Comments per paragraph

• Maybe this does not belong in Trac and should be plugin instead - but the neatest way of collecting user feedback I have ever seen was the Django book ​http://www.djangobook.com/about/comments/.

Nice idea. I can try to make #SectionEditing a tracopt.* optional component, which should then make it easier to implement such a thing as a plugin (or another tracopt.* component eventually).