Edgewall Software
Modify

Opened 8 years ago

Closed 4 years ago

Last modified 4 years ago

#3533 closed enhancement (fixed)

Display shortened revision numbers

Reported by: thomas.moschny@… Owned by: rblank
Priority: normal Milestone: 0.12
Component: version control Version: devel
Severity: minor Keywords:
Cc:
Release Notes:
API Changes:

Description

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.)

Attachments (0)

Change History (9)

comment:1 Changed 8 years ago by cboos

  • Owner changed from cmlenz to cboos
  • Severity changed from normal to minor

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

comment:2 follow-up: Changed 8 years ago by cboos

  • Milestone changed from 0.11 to 0.10
  • Resolution set to fixed
  • Status changed from new to closed

… 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.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 7 years ago by moschny

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:4 Changed 7 years ago by moschny

  • Milestone changed from 0.10 to 0.12

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

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

comment:6 in reply to: ↑ 3 ; follow-up: Changed 7 years ago by 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.

comment:7 in reply to: ↑ 6 Changed 7 years ago by cboos

Replying to cboos:

So I'll change this to use normalized revs.

See r4640.

comment:8 Changed 4 years ago by rblank

  • Milestone changed from next-major-0.1X to 0.12
  • Resolution set to fixed
  • Status changed from reopened to closed

A new Repository.display_rev() has been added in [9559] and implemented for Mercurial in [9560], as part of #9230.

comment:9 Changed 4 years ago by rblank

  • Owner changed from cboos to rblank

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain rblank.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from rblank to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.