Edgewall Software

Opened 19 years ago

Closed 15 years ago

Last modified 15 years ago

#1781 closed defect (fixed)

Link from 'Browser Source' to Subversion Repository URL

Reported by: Ian Leader <__ian.leader__@…> Owned by: Remy Blank
Priority: normal Milestone: 0.12-multirepos
Component: version control/browser Version: devel
Severity: normal Keywords: url multirepos
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:


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)


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.

Attachments (1)

1781-repository-url-r8398.patch (8.1 KB ) - added by Remy Blank 15 years ago.
Patch against MultiRepos adding a "Repository URL" link in the browser.

Download all attachments as: .zip

Change History (31)

comment:1 by d.mills@…, 19 years ago

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.

comment:2 by Ian Leader <__ian.leader__@…>, 19 years ago

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.

comment:3 by markus, 19 years ago

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.

comment:4 by Ian Leader <__ian.leader__@…>, 19 years ago

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

comment:5 by anonymous, 19 years ago

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/

comment:6 by Matthew Good, 18 years ago

Owner: changed from Jonas Borgström to Matthew Good

comment:7 by Christian Boos, 18 years ago

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

comment:8 by Christian Boos, 18 years ago

Milestone: 0.11
Owner: changed from Matthew Good to 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.

comment:9 by Matthew Good, 18 years ago

#4406 has been marked as a duplicate.

comment:10 by Christian Boos, 16 years ago

Keywords: url multirepos added

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.

comment:11 by osimons, 16 years ago

#6804 closed as duplilcate.

comment:12 by christer@…, 16 years ago

Would something like this be what you want?


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.

comment:13 by Christian Boos, 16 years ago

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

comment:14 by techtonik <techtonik@…>, 16 years ago

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.

comment:15 by Remy Blank, 15 years ago

Milestone: 0.130.12
Owner: changed from Christian Boos to Remy Blank

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

by Remy Blank, 15 years ago

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

comment:16 by Remy Blank, 15 years ago

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.

comment:17 by Remy Blank, 15 years ago

Resolution: fixed
Status: newclosed

Patch applied in [8431].

comment:18 by Christian Boos, 15 years ago

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

comment:19 by Christian Boos, 15 years ago

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

in reply to:  19 comment:20 by Remy Blank, 15 years ago

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?

comment:21 by Christian Boos, 15 years ago

It seems… I use r8432 and I have:

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…

comment:22 by Christian Boos, 15 years ago

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

I figured the URL would be simply reused…

comment:23 by Christian Boos, 15 years ago

Implemented for Mercurial in r8435.

comment:24 by Remy Blank, 15 years ago

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.

comment:25 by Remy Blank, 15 years ago

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

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

comment:26 by Remy Blank, 15 years ago

Something like:

  • tracext/hg/backend.py

    diff --git a/tracext/hg/backend.py b/tracext/hg/backend.py
    a b  
    437437                pass
    439439    def get_path_url(self, path, rev):
    440         url = self.options['url']
     440        url = self.options.get('url', '')
    441441        if url:
    442442            if not path or path == '/':
    443                 return url
    444             rev = rev is not None and short(self.hg_node(rev)) or 'tip'
    445             return posixpath.join(url, 'file', rev, path)
     443                if rev is None:
     444                    return url
     445                branch = self.repo[self.hg_node(rev)].branch()
     446                if branch == 'default':
     447                    return url
     448                return url + '#' + branch
    447450    def get_changeset(self, rev):
    448451        return MercurialChangeset(self, self.hg_node(unicode(rev)))

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

comment:27 by Christian Boos, 15 years ago

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

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

comment:28 by Remy Blank, 15 years ago

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.

in reply to:  28 comment:29 by Christian Boos, 15 years ago

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.

comment:30 by Christian Boos, 15 years ago

Milestone: 0.120.12-multirepos

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Remy Blank.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Remy Blank to the specified user.

Add Comment

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