Edgewall Software
Modify

Opened 10 years ago

Last modified 3 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
Release Notes:
API 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 Changed 10 years ago by Christian Boos

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 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by 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.

comment:4 in reply to:  3 ; Changed 10 years ago by 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.

comment:5 in reply to:  4 ; Changed 10 years ago by 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.

comment:6 Changed 9 years ago by Emmanuel Blot

See also ticket:7687:21

comment:7 in reply to:  5 Changed 9 years ago by 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.

comment:8 Changed 8 years ago by Christian Boos

Milestone: 2.0unscheduled

Milestone 2.0 deleted

comment:9 Changed 8 years ago by Joel Lopes Da Silva <joel@…>

Cc: joel@… added

comment:10 Changed 8 years ago by Martin Scharrer <martin@…>

Cc: martin@… added

comment:11 Changed 8 years ago by Christian Boos

Milestone: triagingunscheduled

Milestone triaging deleted

comment:12 Changed 4 years ago by Jun Omae

Cc: Jun Omae added
Keywords: git-submodule added

comment:13 Changed 3 years ago by Ryan J Ollos

Owner: Christian Boos deleted

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.
The owner will be changed from (none) to anonymous.

Add Comment


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