Link from 'Browser Source' to Subversion Repository URL

[Ian Leader <__ian.leader__@…>]

When browsing source in trac, it would be useful to be able to get the Subversion repository URL for the folder or file you are browsing - for example to check out that sub-tree, or to link directly to a file in the repository.

This would require a parameter with the base URL of the repository to be set in trac.ini as there is no way to automatically deduce the URL. Beyond that I think it would be fairly simple to implement.

I would like to see this at the top of the page e.g.

root/tags/trac-0.8 (subversion repository URL for this page)

or

root/tags/trac-0.8 (<URL spelled out>)

in a smaller font just after the path. However, if this was controversial, a good alternative would be to put it in as an 'alternative format' link.

If there's interest in including this in the trunk, I'm happy to do a patch.

[d.mills@…]

I'd be interested in this feature too, but I was wondering: is it possible to code the version into the url? if not, the usefullness of this feature will be seriously limited.

[Ian Leader <__ian.leader__@…>]

It isn't possible to specify a revision when accessing an SVN repo in apache using plain HTTP or HTTPS. However, this is still useful in the following cases:

1. You want to know the URL to put into your svn client to check out or export whatever version you require
2. You want a URL to link to the latest version of a folder/file

I see this as being as much/more about easily getting a URL to use elsewhere, rather than a way of accessing the svn repo directly through your web browser.

[markus]

I agree with Ian. In case you're using the ​svn:// or ​svn+ssh:// protocol it is often much more easy to remember a web address of a project instead of a url to a repository.

[Ian Leader <__ian.leader__@…>]

After some more thought on this, I propose to implement as follows:

1. Show a hyperlink to the repository after the 'internal' path on the 'browse source' pages along the following lines:
   • root/tags/trac-0.8 (​http://svn.edgewall.com/repos/trac/tags/trac-0.8/)
2. All subversion protocols (including ​file://) will be supported
3. Protocol and URL will be specified in trac.ini in the [trac] section:
   • repository_protocol - will contain the repository protocol (one of ​file:/// , ​http://, ​https://, ​svn://, ​svn+ssh://, or blank).
   • repository_URL - URL to the top level of the repository, without the protocol or any leading slash(es) (e.g. svn.edgewall.com/repos/trac/tags/trac-0.8/), or blank

The rationale for separating the protocol from the rest of the URL is to support installations that allow both HTTP and HTTPS access to the repository (e.g. HTTP allowed from the LAN, HTTPS only for external access). If the repository protocol field is set to blank, the repository URL will be formed using the current protocol (HTTP or HTTPS)

If both the repository_protocol and the repository_URL are blank, the link will not appear.

For trac installations operating on a repository subset (see #586), repository_URL specified can be to a sub-folder of the repository, not the top level.

I have a feeling that maybe this should use the versioncontrol layer (see TracDev/VersionControlApi), but the documentation is limited so far, and I can't find mention of version controlprovider implementation-specific configuration parameters, so I'm thinking it's best to go with a simple approach for now.

[anonymous]

there is an url to access old revisions, but it is "secrect" i.e. you should not rely on it forever: ​http://svn.edgewall.com/repos/trac/!svn/bc/1000/tags/

[Christian Boos]

mgood, if you want to implement this, please don't forget to do that in a VersioningSystemBackend independant way.

For example, in mercurial, there could be a link to the manifest in the mercurial cgi server.

e.g. if the currently browsed path is /mercurial, the link would be: http://www.selenic.com/hg/?mf=aec167b2fe2b;path=/mercurial/ (the mf argument being the current changeset id).

[Christian Boos]

Actually, this could be generalized to having a list of "related paths" for the currently browsed path. This would make the implementation doable as a plugin and then the svn backend could do it one way, the Mercurial plugin another way, etc.

Plus this would allow for links to other systems as well, like documentation systems, like the ​DoxygenPlugin.

[Matthew Good]

#4406 has been marked as a duplicate.

[Christian Boos]

Related to some of the changes done in the MultipleRepositorySupport branch and per-repository extra configuration (i.e. r6459). We could try to get the 'url' information from the repository options and if set, automatically add the link to the path being browsed using that URL as a base.

[osimons]

#6804 closed as duplilcate.

[christer@…]

Would something like this be what you want?

​http://zoo.weinigel.se/trac/public/browser/trac/repolink/trunk

Try clicking on "Repo" in the context navigation area.

Warning, this is my first attempt at a trac plugin, so it's probably a very crude solution.

[Christian Boos]

Yep, more or less (plugins (ab)using IRequestFilter are indicative that the appropriate interface is missing).

Here, you use repository_url, which is fine when there's only one repo. With the MultipleRepositorySupport, this will be part of the per-repository metadata, and there, guessing the appropriate repository from the req.path_info will be more difficult, so I'll integrate that in the BrowserModule itself.

So let's say the repolink plugin is the solution for 0.11 and with 0.12 it won't be necessary (and I'll support "legacy" repository_url as well).

[techtonik <techtonik@…>]

I would be against postponing this to 0.12, because even to add patches to Trac itself such information would be very convenient. As you may know windows doesn't have native diff utility and the most convenient way to build a patch is using svn checkout.

[Remy Blank]

I have started working on this in the context of MultiRepos. Nothing to show yet, though.

[Remy Blank]

Patch against MultiRepos adding a "Repository URL" link in the browser.

[Remy Blank]

The patch above adds repository URL information to the repository data, and displays a "Repository URL" link in the browser for paths where the info is available.

• A new attribute url can be associated with each repository:
  • For the default repository, through the [trac] repository_url config option.
  • For repositories defined in trac.ini, through the [repositories] <reponame>.url config option.
  • For repositories defined with the "Repositories" admin panel, in an additional field in the repository detail view.

• If the URL starts with //, the scheme of the current request is prepended to the URL. This allows sites with both http: and https: access to provide the corresponding repository URL.

• Construction of the URL for a specific path is done in the repository instance, so every repository type can create URLs according to its own rules (see comment:7).

• The URL is displayed as a ctxtnav item "Repository URL". This means that the URL itself is not directly visible, but can be easily copied with a "Copy Link Location" in the browser. I have tried displaying the URL next to the path, as suggested in the description, but couldn't find a clean layout.

The patch is against the multirepos branch. Comments welcome.

[Remy Blank]

Patch applied in [8431].

[Christian Boos]

… works fine for me, now with [8432].

[Christian Boos]

Oh, except for the <reponame>.url entries in the TracIni [repositories] section: no Repository URL shown for those.

[Remy Blank]

Replying to cboos:

Oh, except for the <reponame>.url entries in the TracIni [repositories] section: no Repository URL shown for those.

Really? Works here, even with aliases… Could you post your [repositories] section, please? Which revision are you running?

[Christian Boos]

It seems… I use r8432 and I have:

[repositories]
apr.dir = /srv/hg/apr
apr.type = hg
apr.url = http://dserver/hg/apr
apr-util.dir = /srv/hg/apr-util
apr-util.type = hg
apr-util.url = http://dserver/hg/apr-util

and similar…

[Christian Boos]

Oh wait, stupid me, the hg backend needs to implement something, right ;-)

I figured the URL would be simply reused…

[Christian Boos]

Implemented for Mercurial in r8435.

[Remy Blank]

Nice! But does it really make sense to link to the "files" view of HG's web interface? Or should the link always point to the URL used for cloning (and possibly only be displayed for the root of the repository)?

How about named branches? Currently, the link at the root always points to the tip. It would be nice if you're browsing a named branch, that it provides the URL to clone that specific branch.

[Remy Blank]

Oh, and using posixpath.join() is not such a great idea:

>>> posixpath.join("http://localhost", "/")
'/'

[Remy Blank]

Something like:

tracext/hg/backend.py

@@ -437 +437 @@
                 pass
 
     def get_path_url(self, path, rev):
-        url = self.options['url']
+        url = self.options.get('url', '')
         if url:
             if not path or path == '/':
-                return url
-            rev = rev is not None and short(self.hg_node(rev)) or 'tip'
-            return posixpath.join(url, 'file', rev, path)
+                if rev is None:
+                    return url
+                branch = self.repo[self.hg_node(rev)].branch()
+                if branch == 'default':
+                    return url
+                return url + '#' + branch
 
     def get_changeset(self, rev):
         return MercurialChangeset(self, self.hg_node(unicode(rev)))

Be careful that the 'url' key can be missing.

[Christian Boos]

Yes, it make sense, I applied those changes in r8436.

I also kept the old link around in case I change my mind ;-)

[Remy Blank]

One last thing I only noticed after posting: you normally use repo.changectx(node) instead of repo[node], probably for backward compatibility with older Mercurial versions. You may want to do the same here.

[Christian Boos]

Replying to rblank:

… use repo.changectx(node) instead of repo[node], probably for backward compatibility with older Mercurial versions.

Well, I'm actually happy to get introduced to the newer API. I just checked and it looks like the method was introduced for 1.1, so we're still quite backward compatible here, enough so for 0.12. I'll update the TracMercurial page.