svn:externals displayed as folder in listing

[cjunge@…]

It would be nice if it was an option to enable svn:externals (& possibly other version control systems with the same feature) to be displayed inline in the folder/file listing.

Currently the svn:externals is listed at the bottom of the listing for the folder it's applied to. This link can be controlled using the TracIni settings to point directly to the correct repository.

The listing of the folder the external is linked to does not show any reference to the external. This is confusing as a checkout will copy the external into the WC, but there is no visual representation of this in Trac. A folder with a link icon (maybe) and information about the external (& link if configured correctly) would be nice.

Cameron

[Christian Boos]

That would be quite involved, but doable I guess.

The main issue would be some added complexity to SubversionRepository.get_node which would have to decide if the given path actually exist in the repository or is the "extended" repository.

See the ​canonical example:

$ svn propget svn:externals calc
third-party/sounds             http://sounds.red-bean.com/repos
third-party/skins              http://skins.red-bean.com/repositories/skinproj
third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker

When listing the calc folder, it's not that complex to add a special entry for third-party. What's more problematic is for expanding third-party itself: 'calc/third-party' doesn't exist as such in the repository and one has to go upward until a svn:externals is found on a "real" node, then downward to locate the specified entry.

[osimons]

In addition there are the issues related to authentication and authorization of access to remote repository - Trac will not know how to do that on behalf of each user. This is intended to be resolved by user at checkout, and I see no obvious way of doing that - other than to limit the feature to anonomymous read only.

[Christian Boos]

Well, AFAICT, we were not talking of accessing the remote repository, only how to best display the svn:externals information available in the local repository.

i.e. in the example above, Trac would ideally show (using expanded display):

• (D) calc
  • … regular calc entries
  • ® third-party
    • ® sounds
    • ® skins
      • ® toolkit
  • … remaining regular calc entries

where (D) stands for the folder icon and ® for a "remote folder" icon. All this information is normally available to users having the rights to look at "calc", if I'm not mistaken, as it's the content of a property on that node.

[osimons]

Replying to cboos:

Well, AFAICT, we were not talking of accessing the remote repository, only how to best display the svn:externals information available in the local repository.

Ah. My misunderstanding. Just parsing and displaying 'inline' would have no such issues, of course.

[cjunge@…]

Replying to osimons:

Replying to cboos:

Well, AFAICT, we were not talking of accessing the remote repository, only how to best display the svn:externals information available in the local repository.

Ah. My misunderstanding. Just parsing and displaying 'inline' would have no such issues, of course.

That is exactly what I was meaning. Actually accessing the remote repository wouldn't be feasible (probably), but displaying inline would make it obvious that the folders are part of the repository.

Of course, it might be required to walk up the folder tree to obtain all the externals, but that could be cached.

[Emmanuel Blot]

See also ticket:7687:21

[nattgris]

Replying to cjunge@…:

Replying to osimons:

Replying to cboos:

Well, AFAICT, we were not talking of accessing the remote repository, only how to best display the svn:externals information available in the local repository.

Ah. My misunderstanding. Just parsing and displaying 'inline' would have no such issues, of course.

That is exactly what I was meaning. Actually accessing the remote repository wouldn't be feasible (probably), but displaying inline would make it obvious that the folders are part of the repository.

While I acknowledge that a remote repository may be troublesome to access, I would really like the possibility to follow an externals definition targeting a local repository. I mentioned this in #7687:22. The contents of the targeted repository path should be shown inline, just as if it was a regular subdir, though maybe with a different icon. That way the browser would look similar to a checked out working copy of the project.

So given a SVN repo at /var/lib/svn, the browser for a trac environment connected to /var/lib/svn/project1 should display the contents of /var/lib/svn/modules/module1 when expanding project1/module1 if the svn:externals property of project1 was set to '^/modules/module1 module1'. This behavior is similar, but not identical, to #6615 but that one requires another trac environment connected to /var/lib/svn/modules/module1, and it does not mention displaying the contents inline in the browser.

[Christian Boos]

Milestone 2.0 deleted

[Christian Boos]

Milestone triaging deleted