Inter-project links

[david.larsson@…]

It would be nice to be able to link between projects (on the same server), e.g. [link:/trac/TestPage A test page in the trac project]. I know I can use a full URL, but I want to use the same protocol (https/http) in the link as the current user session. (This is because I force user login on https but not on http).

[daniel]

A possible syntax, that also remains compatible with InterWikiLinks?:

• project:#42 == project:ticket:42
• project:WikiPage == project:wiki:WikiPage

See also: http://c2.com/cgi/wiki?InterWiki, http://c2.com/cgi/wiki?InterWiki

[daniel]

A more advanced example:

{{{[project:changeset:42 my changeset]}}.

[daniel]

Oops, didn't get quoting on that previous comment:

[project:changeset:42 my changeset]

[daniel]

the <project> part should be automatically detemermined for locally hosted projects, but it should also reference an Intermap-style map, to retain the InterWiki semantic.

[cboos@…]

Intertrac patch, made against 1017

[cboos@…]

This ticket seems related to my need of handling intertrac links.

An intertrac link is a 1-character prefix you put before the ticket/changeset number, e.g. #T234 or [T1010]. It can also be set in a module href: ticket:T:234, changeset:T:1010.

Each prefix should be documented in the [intertrac] section of the conf/trac.ini file:

[intertrac]
T.title = Edgewall Trac
T.href = http://projects.edgewall.com/trac

(I hope this patch gets noticed, otherwise I'll create a new ticket for it)

Patch added intertrac.1017.diff

[cboos@…]

Oops, the patch initially posted ( Fri Nov 5 09:37:01 2004. ) had a little typo in it, I just uploaded the fixed version.

The typo was:

trac/WikiFormatter.py

@@ -186 +186 @@
     def _tickethref_formatter(self, match, fullmatch):
         intertrac = fullmatch.group('t_intertrac')
         if intertrac:
-            number = int(match[1+len(intertrac):-1])
+            number = int(match[1+len(intertrac):])
             href, title, _class = self._intertrac_link(intertrac)
             return '<a class="%s" title="%s" href="%s/ticket/%d">#%d</a>' % (_class, title, href, number, number)
         else:

[cboos@…]

Fixed version of the Intertrac patch against 1017.

[cmlenz]

Isn't this just a special case of #40 (InterWiki links)?

[cboos@…]

> Isn't this just a special case of #40 (InterWiki links)?

I think that an InterWiki link is a kind of InterTrac link, as the proposed cross-referencing is not only for Wiki pages, but for all trac related objects: wikis, tickets and changesets. That's why I added my intertrac patch here (#234) and not there (#40).

I find it useful to have quick shortcuts to other trac projects (like #T234 to refer to the #234 ticket for Trac), because sometimes you work on a project that involves multiple source repositories (SVN repositories only for now).

For instance, I have a trac database set up on a local source code repository for 3rd party software, which is managed by SVK. In there, I mirror the edgewall trac SVN repository.

I often need to refer to bugs and changesets from the official trac database for Trac when I hack my local version of Trac. I also often refer to our "main" SVN repository, under the control of a different trac database.

[cboos@…]

I just fixed an embarassing bug in my patch:

!diff
=== WikiFormatter.py
==================================================================
--- WikiFormatter.py  (revision 1072)
+++ WikiFormatter.py  (local)
@@ -116,7 +116,7 @@
               r"""(?P<tickethref>!?#(?P<t_intertrac>[a-zA-z]?)\d+)""",
               r"""(?P<changesethref>!?\[(?P<c_intertrac>[a-zA-z]?)\d+\])""",
               r"""(?P<reporthref>!?\{\d+\})""",
-              r"""(?P<modulehref>!?((?P<modulename>bug|ticket|browser|source|repos|report|changeset|wiki|milestone|search):(?P<m_intertrac>[a-zA-z]:?)(?P<moduleargs>(&#34;(.*?)&#34;|'(.*?)')|([^ ]*[^\., \)]))))""",
+              r"""(?P<modulehref>!?((?P<modulename>bug|ticket|browser|source|repos|report|query|changeset|wiki|milestone|search):(?P<m_intertrac>[a-zA-z]:)?(?P<moduleargs>(&#34;(.*?)&#34;|'(.*?)')|([^ ]*[^\., \)]))))""",
               r"""(?P<wikilink>!?(^|(?<=[^A-Za-z]))[A-Z][a-z]+(?:[A-Z][a-z]*[a-z/])+(?=\Z|\s|,|\.|:|\)))""",
               r"""(?P<fancylink>!?\[(?P<fancyurl>([a-z]+:[^ ]+)) (?P<linkname>.*?)\])"""]

[cboos@…]

(Once again, coffee badly needed...)

WikiFormatter.py

@@ -116 +116 @@
               r"""(?P<tickethref>!?#(?P<t_intertrac>[a-zA-z]?)\d+)""",
               r"""(?P<changesethref>!?\[(?P<c_intertrac>[a-zA-z]?)\d+\])""",
               r"""(?P<reporthref>!?\{\d+\})""",
-              r"""(?P<modulehref>!?((?P<modulename>bug|ticket|browser|source|repos|report|changeset|wiki|milestone|search):(?P<m_intertrac>[a-zA-z]:?)(?P<moduleargs>(&#34;(.*?)&#34;|'(.*?)')|([^ ]*[^\., \)]))))""",
+              r"""(?P<modulehref>!?((?P<modulename>bug|ticket|browser|source|repos|report|changeset|wiki|milestone|search):(?P<m_intertrac>[a-zA-z]:)?(?P<moduleargs>(&#34;(.*?)&#34;|'(.*?)')|([^ ]*[^\., \)]))))""",
               r"""(?P<wikilink>!?(^|(?<=[^A-Za-z]))[A-Z][a-z]+(?:[A-Z][a-z]*[a-z/])+(?=\Z|\s|,|\.|:|\)))""",
               r"""(?P<fancylink>!?\[(?P<fancyurl>([a-z]+:[^ ]+)) (?P<linkname>.*?)\])"""]
 

[cboos@…]

...hum, what about a feature to edit/remove embarassingly stupid comments :)

WikiFormatter.py

@@ -116 +116 @@
               r"""(?P<tickethref>!?#(?P<t_intertrac>[a-zA-z]?)\d+)""",
               r"""(?P<changesethref>!?\[(?P<c_intertrac>[a-zA-z]?)\d+\])""",
               r"""(?P<reporthref>!?\{\d+\})""",
-              r"""(?P<modulehref>!?((?P<modulename>bug|ticket|browser|source|repos|report|changeset|wiki|milestone|search):(?P<m_intertrac>[a-zA-z]:?)(?P<moduleargs>(&#34;(.*?)&#34;|'(.*?)')|([^ ]*[^\., \)]))))""",
+              r"""(?P<modulehref>!?((?P<modulename>bug|ticket|browser|source|repos|report|changeset|wiki|milestone|search):(?P<m_intertrac>[a-zA-z]:)?(?P<moduleargs>(&#34;(.*?)&#34;|'(.*?)')|([^ ]*[^\., \)]))))""",
               r"""(?P<wikilink>!?(^|(?<=[^A-Za-z]))[A-Z][a-z]+(?:[A-Z][a-z]*[a-z/])+(?=\Z|\s|,|\.|:|\)))""",
               r"""(?P<fancylink>!?\[(?P<fancyurl>([a-z]+:[^ ]+)) (?P<linkname>.*?)\])"""]
 

[mgood]

Well, it looks like cboos put [1505] in his branch related to this. I would prefer the original syntax proposed by daniel. The patch apparently supports arbitrary length names, although cboos tends to use a single character. I think that the syntax used by [1505] is ok if it is just a single character name, but for longer names I think the original syntax would work better.

I think we want to focus on handling the longer names, since for multi-project setups people will want to use the project's path as its InterTrac name. This will be important for forwards compatibility, since as daniel noted earlier, we should provide out-of-the-box support for linking to other projects in a multi-project installation.

[cboos]

Well, I don't mind changing in favor of <project>:<module>:<id>, instead of <module>:<project>:<id>, for long links.

However, I largely prefer #<project><id> over <project>:#<id> and [<project><id>] over <project>:[<id>], for short-hand links.

I'll also have a look how to handle InterWiki links (#40) at the same time.

[mgood]

Well, besides just a personal preference for <project>:#<id> and the equivalents for other modules, the problem I can see with #<project><id> is possible ambiguities. Particularly, if the project name contains a number, it becomes difficult or impossible to determine what's part of the project name and what's the id. Numbers are valid for project URLs, so there's a chance that people are using them in multi-project setups. I don't think : characters are nearly as likely to be in a project URL as a number would be.

[cboos]

#<project><id> ... ambiguities. Particularly, if the project name contains a number

I see. My original idea was not to use the project name, but a project key, a kind of shortcut, e.g. T for Trac's Trac, most of the time one letter, but I allowed for more in case disambiguation is needed.

Now I also see the benefit of using the environment's name, for automatic linking into a Trac hosted by the same server, removing the need of setting up an [intertrac] section in TracIni.

Anyway, one can have the full project name and additionally define a project key, e.g. one of our environment is bct_repository: you can see it's more convenient to type #b123 than bct_repository:#123.

[cboos]

I tried to get the best of both worlds in [1508]. See the updated InterTrac specification. Please test!

[trac@…]

One simple way to fulfill David's original request is to use relative URLs, which use the same protocol as the current page. If you need to construct an absolute URL that uses the same protocol, you can use the relatively unknown protocol-relative URL link syntax:

//hostname.domain/path/to/filename.ext

(just leave off the http:)

[cboos]

I think the InterTrac feature is candidate for merging, see [1569].

Feedback welcomed!

[ebcom]

Using URLs (relative or absolute) is a bad idea: What about if the server name changes, or if the projects change on the server?: all the Wiki syntax (including pages, tickets, milestones, etc.) would have to be updated ;-(

InterTrac proposal seems nice. I hope it would be merged (very) soon into the trunk, as the need for InterTrac links is increasing every day.

Any comment from C.Lenz ?

[cboos]

It would help to get some feedback about the feature. You can do a checkout of the intertrac-branch

svn co http://svn.projects.edgewall/trac/branches/cboos-dev/intertrac-branch

and setup several test environments, all managed by one tracd server, and tell us what you think.

Btw, if you rename an environment, you either have to rename the links or you have to setup an alias, e.g.

[intertrac]
# 'testproj' is now named 'project', but let's keep the intertrac links working
testproj = project

[cboos]

The feature was reimplemented against the current trunk.

Check out r1912.

Note: The InterTrac branch is a superset of the TracDiff branch. This has the advantage of needing less work for me in order to stay in sync with the trunk in all of my branches, and has the only disadvantage of needing a bit of work if one wants to isolate the feature.

But this isolation work should not happen often, in fact at most once if we decide to integrate InterTrac and not TracDiff, whereas the synchronization of the branches with the trunk happens quite regularly...

[anonymous]

이렇게 올리면 되는걸까요?

[cboos]

This will be post-poned to 1.0.

The InterTrac branch will be actively maintained meanwhile, and a patch for each released 0.9 version will be uploaded here.

[cboos]

I created a special purpose ticket for the branch integration: #2041. You can find the patches against 0.9.x there.

[cboos]

The syntax proposed by mgood is not working anymore for changesets and reports, because of issues like #1153 and #2240.

Only ticket links like trac:#234 are still working that way, so now there's the question to keep that as special cases or not.

Other forms of shorthand intertrac links still work (e.g. [T1505] or [trac 1505] and #T234).

[cboos]

Inter-project links (InterTrac links) are now part of the mainstream Trac, since r2839.