Shorter description of files in a changeset

[s.lipnevich@…]

To make changeset file list more organized, Trac may calculate the longest common path for all files and list filenames relative to this path. Presently (using r3607 as an example):

Files: branches/debian-dev/sid/debian/changelog
       branches/debian-dev/sid/debian/control

Proposed:

Location: branches/debian-dev/sid/debian
Files:    changelog
          control

[Christian Boos]

That was already requested for the Timeline (#3274), but the same code could be reused to implement this.

    location = os.path.dirname(os.path.commonprefix(files))

The idea is quite interesting, as I also have the need to deal with very deep repository structures at times…

[Emmanuel Blot]

This should be implemented as an optional feature (i.e. with a config option in trac.ini)

[Christian Boos]

Ok, what about:

[changeset]
show_common_location = yes

[Emmanuel Blot]

I'm not really good at picking option names, it's up to you ;-)

[Matthew Good]

Replying to cboos:

    location = os.path.dirname(os.path.commonprefix(files))

Note that "commonprefix" works on sequences, which can lead to undesired behavior when using strings:

>>> files = ['trunk/trac/env.py', 'trunk/templates/index.cs']
>>> os.path.commonprefix(files)
'trunk/t'

So, it's usually best to split the strings on path separators, then join them back:

>>> '/'.join(os.path.commonprefix([f.split('/') for f in files]))
'trunk'

Replying to eblot:

This should be implemented as an optional feature (i.e. with a config option in trac.ini)

Why? I prefer not to make every UI change an option. Every option just makes trac.ini and its documentation larger and more confusing. I don't really see a particular reason not to display the base path of the changes.

[Emmanuel Blot]

Replying to mgood:

Why? I prefer not to make every UI change an option. Every option just makes trac.ini and its documentation larger and more confusing. I don't really see a particular reason not to display the base path of the changes.

Because it would prevent from copy&pasting from the browser to a SVN client or an editor, for example. The added value for small changesets (i.e. a couple of changed files) isn't worth it, IMHO.

[Christian Boos]

Thanks matt, I thought about that (that's why I did a os.path.dirname on the result), but the way you suggested is better as it copes with the case the common prefix itself is in the list (like this would happen for an addition or a prop change on the top dir).

As for the configurability of this, I also think it's a bit overkill. And even for the reason explained by manu, I think it's more something that the user should be able to tweak according to his own preferences, rather than the preference of the site administrator. Btw, we have a lot of little issues like that where it would actually be better to leave the ultimate decision up to the user (i.e. fetch the info from the session, and have a UI for managing this in the user Settings page).

[Emmanuel Blot]

I have not thought about a per-session settings but you're absolutely right Christian, this would be a better option than a per-server setting. I still hope however that this new feature will not be implemented without a way to disable it (per-user setting would be nice)

[Christopher Lenz]

For the record, I agree with Matt that we shouldn't add options unless it's really necessary. Options mean a lot of overhead: users need to learn about them, they need to be documented, you need to test changes with both paths (option enabled and disabled), etc.

In this particular case, I don't see any good reason why someone would not want to proposed behavior.

[Christian Boos]

So I think I have now a nice implementation for this one, see r4676.

For the use case mentioned by eblot (be able to copy the full entry), that's still possible when going on the diff section corresponding to each entry, as the path is still displayed in full in the diff heading.

If really there's strong pressure for making it possible to disable the feature, we can still add that option later, but first… try it out!