Display shortened revision numbers

[thomas.moschny@…]

Version control systems other than subversion might have substantial longer revision identifiers (e.g. Mercurial, Monotone). These revision ids should not always be displayed to the user in their entirety.

To solve this, a method should be added to the vc-api that lets the vc-backend convert a "full" revision id into a "displayed" revision number.

An additional parameter could choose the style ("short", "mid-size", "full", whatever...), depending on the context where the revision id is to be displayed.

(The alternate approach, to modify the backend so that it always hands shortened revision ids to trac, seems very hackish to me.)

[cboos]

Repository.short_rev(rev) (Return a compact representation of a revision in the repos) was added a while back (r2669) ...

[cboos]

... during my first VcRefactoring for 0.10.

Note that after the upcoming blame support, the short_rev has an additional use, as we'll require that Node.get_annotations returns a list of short revs, whereas Changeset.rev can still be either a short or a long rev.

[moschny]

Replying to cboos:

Repository.short_rev(rev) (Return a compact representation of a revision in the repos) was added a while back (r2669) ...

Yeah, I know, but it was only used for the diffs of the changeset view. But the timeline for example shows the complete revision, which is 40 chars wide for TracMonotone?, and thus clutters up the timeline view.

I think we should have three sizes (proposed lengths for monotone in parens)

• short (4 chars): for diff and annotate
• middle (8 chars): for the timeline
• normal (40 chars): elsewhere

Replying to cboos:

Note that after the upcoming blame support, the short_rev has an additional use, as we'll require that Node.get_annotations returns a list of short revs,

Which is not good. Inside Trac, we should never use shortened revision numbers as they can be ambiguous! It would not be clear to which changeset (i.e. revision) the shortened revision id should be linked to.

It's only about not always displaying the revision numbers in their entire length to the user, not about using any form of shortened rev internally.

[moschny]

Setting the milestone to 0.12, there are probably some more vc refactorings to be done.

[moschny]

See also: https://pacopablo.com/irclogs/2006/05/13#T14:15:31 for the archived version of a discussion on irc about that issue.

[cboos]

Replying to moschny:

Replying to cboos:

Repository.short_rev(rev) (Return a compact representation of a revision in the repos) was added a while back (r2669) ...

Yeah, I know, but it was only used for the diffs of the changeset view. But the timeline for example shows the complete revision, which is 40 chars wide for TracMonotone?, and thus clutters up the timeline view. I think we should have three sizes (proposed lengths for monotone in parens) * short (4 chars): for diff and annotate * middle (8 chars): for the timeline * normal (40 chars): elsewhere

Ok... thanks for the reminder ;)

Replying to cboos:

Note that after the upcoming blame support, the short_rev has an additional use, as we'll require that Node.get_annotations returns a list of short revs,

Which is not good. Inside Trac, we should never use shortened revision numbers as they can be ambiguous! It would not be clear to which changeset (i.e. revision) the shortened revision id should be linked to.

You're absolutely right, sorry about that. There were two reasons for that:

• the rev is used in a CSS class attribute, so I didn't want to get the ":" character in it (which Mercurial adds when [hg] show_rev = true. That was admittedly a hack ;)
• I wanted to be able to display an histogram of the changes, and for that a sequence number was handy. But that's also not the proper spec for the short_rev (it only happens to be that for svn and hg).

So I'll change this to use normalized revs.

[cboos]

Replying to cboos:

So I'll change this to use normalized revs.

See r4640.