Edgewall Software
Modify

Opened 13 years ago

Last modified 4 years ago

#4412 new enhancement

batch copy/rename wiki pages

Reported by: ittayd@… Owned by:
Priority: normal Milestone: next-major-releases
Component: wiki system Version: 0.10.3
Severity: normal Keywords: batch wikirename wikicopy
Cc: itamarost@…, franz.mayer@… Branch:
Release Notes:
API Changes:

Description (last modified by Christian Boos)

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.

Attachments (0)

Change History (19)

comment:1 by Noah Kantrowitz <coderanger@…>, 13 years ago

comment:2 by anonymous, 13 years ago

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)

comment:3 by Christian Boos, 13 years ago

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. TracOnWindowsTrac0.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.

comment:4 by ittayd@…, 13 years ago

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?

comment:5 by anonymous, 13 years ago

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)

in reply to:  3 comment:6 by anonymous, 13 years ago

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. TracOnWindowsTrac0.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

in reply to:  3 comment:7 by ilias@…, 13 years ago

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)

in reply to:  4 ; comment:8 by Christian Boos, 13 years ago

Component: generalwiki

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

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


...

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.

in reply to:  8 comment:9 by anonymous, 13 years ago

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 ;-) )

comment:10 by Christian Boos, 13 years ago

Resolution: duplicate
Status: newclosed

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).

comment:11 by Christian Boos, 9 years ago

Keywords: wiki batch rename copy added
Milestone: next-major-0.1X
Resolution: duplicate
Status: closedreopened

Reopening for implementing comment:8.

Something similar will also be needed for a plain copy.

comment:12 by Christian Boos, 9 years ago

Keywords: wikirename wikicopy added; wiki rename copy removed

comment:13 by Itamar Ostricher, 9 years ago

Cc: itamarost@… added

comment:14 by Christian Boos, 7 years ago

#10648 was closed as duplicate.

in reply to:  3 comment:15 by Christian Boos, 7 years ago

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).

comment:16 by Christian Boos, 7 years ago

Description: modified (diff)
Summary: cross cutting wiki versionsbatch copy/rename wiki pages

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)

comment:17 by franz.mayer@…, 6 years ago

Cc: franz.mayer@… added

in reply to:  16 comment:18 by franz.mayer@…, 6 years ago

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).

comment:19 by Ryan J Ollos, 4 years ago

Owner: Jonas Borgström removed
Status: reopenednew

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned. Next status will be 'new'.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.