batch copy/rename wiki pages

[ittayd@…]

Use cases

cross cutting wiki versions

If I have a product in version 1.x and I'm about to release 2.0, there are probably many changes to the wiki. However, I'd like to still retain a view of the 1.x wiki, for users of 1.x. Moreover, the 1.x wiki may continue to change with releases to the 1.x stream.

[Noah Kantrowitz <coderanger@…>]

See TighterSubversionIntegration.

[anonymous]

yes this would be the framework.

but what is still needed is to propogate it to the web level. so if in the start page i put 'version 1.x docs' and 'version 2.x docs' links, then choosing each will open the pages in the right versions, where the links in them also point to the right versions etc. by 'versions' i of course mean the product versions, which are very different from the pages' versions.

maybe even with easy access to all 'product versions' of a page (so a user can see how FeatureA was in 1.x and in 2.x)

[Christian Boos]

Well, I'm not sure if it's the optimal solution, but I've started here to rename a few docs with the appropriate release prefix, e.g. TracOnWindows → Trac0.9/TracOnWindows. Now the TracOnWindows page applies to 0.10, and when 0.11 will be the current one, that page will be moved to Trac0.10/TracOnWindows etc.

Another option is to add a suffix with the version, like TracDev/ReleaseNotes/0.10 and TracDev/ReleaseNotes/0.11, though this is less flexible for the reasons exposed in the following.

The first way would work for the TracGuide as well, as the TracGuideMacro supports relative links within the current "scope" (as I did that originally for translations, e.g. TranslationFr/TracGuide). The regular wiki links within a given scope (e.g. a reference to TracBrowser within a "Trac0.9/xyz" page) would still go to the "latest" and toplevel page ("TracBrowser" in this example), so that's not ideal.

This will change with 0.11, as relative links could be used: if the links are written as [./TracBrowser TracBrowser] then the content of the page can be moved from the toplevel to within a version prefixed page (see also r4442).

A macro could eventually be written to view all the other [Version%/DocPage] from a given [VersionX/DocPage], like you suggested.

Lastly, the Wiki pages could be saved within the repository (like we do in source:/trunk/wiki-default), so it will be kept together with the code when creating tags and branches. Two problems with this approach: it's not easy to further edit the documentation for an old release (i.e. can't be done in the web interface, it involves a checkout and further commits). Second, when the wiki page is rendered, the links would still point to the current documentation within the wiki. With 0.11 and relative links, it might be possible to keep consistent links (same source:/<path> prefix), but I have to check this, as I'm not sure it already works.

[ittayd@…]

i'm not sure you will need a 'checkout and commit'. same as the code browser can access all code versions without checkout, couldn't it also push changes?

[anonymous]

how will you move the pages?

also, the schema you suggested (versioning hierarchy) sounds good, but sounds also like either a lot of work (moving page-by-page), or another case of duplicating functionality found in VC systems (branching)

[anonymous]

Replying to cboos:

Well, I'm not sure if it's the optimal solution, but I've started here to rename a few docs with the appropriate release prefix, e.g. TracOnWindows → Trac0.9/TracOnWindows. Now the TracOnWindows page applies to 0.10, and when 0.11 will be the current one, that page will be moved to Trac0.10/TracOnWindows etc.

see this thread:

​WARNING - Encoding Hierarchy into the Wiki Name

[ilias@…]

Replying to cboos: …

Lastly, the Wiki pages could be saved within the repository (like we do in source:/trunk/wiki-default), so it will be kept together with the code when creating tags and branches.

Keeping wiki pages (optional) within the repository has several other benefits.

Two problems with this approach: it's not easy to further edit the documentation for an old release (i.e. can't be done in the web interface, it involves a checkout and further commits).

#4414 (could be implemented, would increase trac's usage flexibility)

[Christian Boos]

Replying to ittayd@qlusters.com:

i'm not sure you will need a 'checkout and commit'. same as the code browser can access all code versions without checkout, couldn't it also push changes?

Not exactly. So far we only read from the repository. But it could be done, eventually.

how will you move the pages?

See #1106. I could imagine doing that in a way that would allow a "batch rename" operation, something like:

---

Rename Page

From: To:

Note: You can use the '%' character as a wildcard in the above From and To fields.

---

…as a first step, followed by a confirmation step:

---

Confirm renaming

TracBrowser to Trac0.10/TracBrowser
TracRevisionLog to Trac0.10/TracRevisionLog
TracTermsFr to Trac0.10/TracTermsFr
...

---

I concede it's a bit similar to branching (a la Subversion, i.e. branch by copy), yes. But keep in mind that not everyone has a repository at hand. The main argument behind TighterSubversionIntegration was: as we already have as a prerequisite all the machinery needed to create a repository and version data in it, why not use it?. Things have a bit changed since then, as Subversion (or another versioning system backend) is not required to be present anymore. That's not to say that I've given up on the Tighter… approach, but it certainly needs to be rewritten and adapted to the current status of Trac.

[anonymous]

Replying to cboos:

I concede it's a bit similar to branching (a la Subversion, i.e. branch by copy), yes. But keep in mind that not everyone has a repository at hand. The main argument behind TighterSubversionIntegration was: as we already have as a prerequisite all the machinery needed to create a repository and version data in it, why not use it?. Things have a bit changed since then, as Subversion (or another versioning system backend) is not required to be present anymore. That's not to say that I've given up on the Tighter… approach, but it certainly needs to be rewritten and adapted to the current status of Trac.

I totally agree. I don't have subversion and would hate to need to set it up in order to use trac. I think there are lighter alternatives, the one i like best is mercurial. it took me no time to start using it (and, it is written in python ;-) )

[Christian Boos]

To conclude the discussion, this can be handled using the WikiPageNames hierarchy, but it's true that there should be increased support for the hierarchy (#4507) and the rename of pages, like proposed in comment:8 (see #1106).

[Christian Boos]

Reopening for implementing comment:8.

Something similar will also be needed for a plain copy.

[Christian Boos]

#10648 was closed as duplicate.

[Christian Boos]

Replying to cboos:

… A macro could eventually be written to view all the other [Version%/DocPage] from a given [VersionX/DocPage], like you suggested.

And this macro would have much in common with the TranslatedPages macro from #1513 (well, the early version of it).

[Christian Boos]

Note that for integrating the copy operation into this interface, we could replace:

[ ] Leave a redirection page at the old location

with:

 ,- Operation ----------------------------------------------------------------------
 | ( ) copy  (the old location is left unchanged) 
 | ( ) move  (no page left at the old location)
 | ( ) move and create redirect page (leave a redirection page at the old location)
 |     |See $NEWPAGE_____| (content of the redirect page)

[franz.mayer@…]

Replying to cboos:

 ,- Operation ----------------------------------------------------------------------
 | ( ) copy  (the old location is left unchanged) 
 | ( ) move  (no page left at the old location)
 | ( ) move and create redirect page (leave a redirection page at the old location)
 |     |See $NEWPAGE_____| (content of the redirect page)

I like that. It's very clear.

One thing maybe: for option move should be a hint that all sub-pages are also moved. For example: "move (no page starting with "$OLDPAGE" will be left at the old location)"

Btw: this feature is wanted by several Trac-Users (in our company and out there, see ​Trac-Users mailing list).