Edgewall Software
Modify

Opened 17 years ago

Last modified 9 years ago

#6474 new enhancement

svn:externals displayed as folder in listing

Reported by: cjunge@… Owned by:
Priority: normal Milestone: unscheduled
Component: version control/browser Version:
Severity: minor Keywords: svn:externals git-submodule
Cc: joel@…, martin@…, Jun Omae Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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

Attachments (0)

Change History (13)

comment:1 by Christian Boos, 17 years ago

Keywords: svn:externals added
Milestone: 2.0

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.

comment:2 by osimons, 17 years ago

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.

comment:3 by Christian Boos, 17 years ago

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.

in reply to:  3 ; comment:4 by osimons, 17 years ago

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.

in reply to:  4 ; comment:5 by cjunge@…, 17 years ago

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.

comment:6 by Emmanuel Blot, 15 years ago

See also ticket:7687:21

in reply to:  5 comment:7 by nattgris, 15 years ago

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.

comment:8 by Christian Boos, 14 years ago

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:9 by Joel Lopes Da Silva <joel@…>, 14 years ago

Cc: joel@… added

comment:10 by Martin Scharrer <martin@…>, 14 years ago

Cc: martin@… added

comment:11 by Christian Boos, 14 years ago

Milestone: triagingunscheduled

Milestone triaging deleted

comment:12 by Jun Omae, 10 years ago

Cc: Jun Omae added
Keywords: git-submodule added

comment:13 by Ryan J Ollos, 9 years ago

Owner: Christian Boos removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


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