Edgewall Software
Modify

Opened 12 years ago

Closed 10 years ago

#11050 closed defect (fixed)

Hash changeset ids are not allowed in revision log

Reported by: sterkrig@… Owned by: Jun Omae
Priority: high Milestone: 1.0.6
Component: wiki system Version: 1.0.1
Severity: normal Keywords: traclinks, changeset, revision, log, hg, git
Cc: Branch:
Release Notes:

Allow hash changeset ids and branch names in revision ranges, e.g. [rev1:rev2], log:@rev1:rev2, log:@branch1:master.

API Changes:
Internal Changes:

Description

According to TracLinks, the following markup styles are available for revision logs:

r1:3, [1:3] or log:@1:3, log:trunk@1:3, [2:5/trunk]

But I'm unable to use hash ids in either one of them. Let's try with cboos.git and its topmost changesets:

The same goes for Mercurial repos, but at least there are revnumbers, although they are of limited use due to their nature.

There are similar problems with default repository, but since here default repo is kept in SVN (what a shame!) I can't demonstrate it :)

Attachments (0)

Change History (15)

in reply to:  description comment:1 by Christian Boos, 12 years ago

Milestone: next-stable-1.0.x
  • log:cboos.git@ec351621:f6b72a6a (had to be quoted, otherwise a ValueError is raised);

This one is worth a fix on 1.0-stable.

The rest also deserve to be supported in some future version, I agree.

comment:2 by Christian Boos, 12 years ago

Priority: normalhigh

comment:3 by anonymous, 11 years ago

Keywords: traclinks added; links removed

comment:4 by Jun Omae, 11 years ago

Milestone: next-stable-1.0.x1.0.3
Owner: set to Jun Omae
Status: newassigned

Proposed changes can be found in log:jomae.git:t11050.

comment:5 by Ryan J Ollos, 11 years ago

Keywords: traclinks,changeset,revision,log,hg,git → traclinks, changeset, revision, log, hg, git

comment:6 by Jun Omae, 10 years ago

Rebased the changes on latest of 1.0-stable, jomae.git@t11050v2.

comment:7 by Peter Suter, 10 years ago

Seems to work well, and also helps with #11888.

I suspect in RevRanges.truncate it should be:

  • trac/versioncontrol/web_ui/util.py

    diff -r 01c646dbc14b -r 3b4fe9b8e444 trac/versioncontrol/web_ui/util.py
    a b  
    292292                break
    293293            pairs.append(p)
    294294        if pairs:
    295             self.a = pairs[0][0]
    296             self.b = pairs[-1][1]
     295            ranges.a = pairs[0][0]
     296            ranges.b = pairs[-1][1]
    297297        return ranges
    298298
    299299    def _reduce(self):

trac.versioncontrol.web_ui.util.RevRanges is a generalization of trac.util.Ranges that supports non-integer revisions, right? The comments from there help a lot.

RevRanges doesn't seem to use the path parameter, and only uses repos.normalize_rev from repos. Maybe it could become something like trac.util.GeneralRanges(r=[], normalize=int).

Last edited 10 years ago by Peter Suter (previous) (diff)

comment:8 by Jun Omae, 10 years ago

Milestone: 1.0.31.0.4

comment:9 by Ryan J Ollos, 10 years ago

Milestone: 1.0.41.0.5

comment:10 by Jun Omae, 10 years ago

Milestone: 1.0.51.0.6

Retargeting. Revised changes can be found in jomae.git@t11050v2. However, that is still broken. https://github.com/libgit2/pygit2/compare/v0.21.3...v0.21.4 shows 35 commits but Trac shows 9 revisions for log:@v0.21.3:v0.21.4.

in reply to:  10 ; comment:11 by Jun Omae, 10 years ago

Milestone: 1.0.61.0.5

Again.

Retargeting. Revised changes can be found in jomae.git@t11050v2. However, that is still broken. https://github.com/libgit2/pygit2/compare/v0.21.3...v0.21.4 shows 35 commits but Trac shows 9 revisions for log:@v0.21.3:v0.21.4.

That occurs when log view with revision ranges walks merge commits. When the log view with revision ranges, Node.get_history(limit=2) is repeatedly called to retrieve next revision until the end of revision ranges. A merge commit has usually two parent commits. However Node.get_history(limit=2) returns only one of the parents….

We should create a new ticket for another issue, so I'll push proposed changes if no objections.

in reply to:  11 comment:12 by Jun Omae, 10 years ago

That occurs when log view with revision ranges walks merge commits. When the log view with revision ranges, Node.get_history(limit=2) is repeatedly called to retrieve next revision until the end of revision ranges. A merge commit has usually two parent commits. However Node.get_history(limit=2) returns only one of the parents….

We should create a new ticket for another issue, so I'll push proposed changes if no objections.

That issue is fixed in [69ff00b96/jomae.git].

comment:13 by Jun Omae, 10 years ago

Milestone: 1.0.51.0.6

I found breakages in the proposed changes. More testing is needed. Retargeting to next stable.

comment:14 by Jun Omae, 10 years ago

Again and again. Proposed changes in log:jomae.git@t11050v3. I'll push it at start of milestone:1.0.6.

comment:15 by Jun Omae, 10 years ago

Release Notes: modified (diff)
Resolution: fixed
Status: assignedclosed

Committed in [13919] and merged to trunk in [13920].

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jun Omae.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jun Omae to the specified user.

Add Comment


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