cross cutting wiki versions

[ittayd@…]

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)

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

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)

[cboos]

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

[cboos]

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