Edgewall Software
Modify

Opened 6 years ago

Closed 4 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:
Release Notes:

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

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

comment:1 in reply to:  description Changed 6 years ago by Christian Boos

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 Changed 6 years ago by Christian Boos

Priority: normalhigh

comment:3 Changed 5 years ago by anonymous

Keywords: traclinks added; links removed

comment:4 Changed 5 years ago by Jun Omae

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 Changed 5 years ago by Ryan J Ollos

Keywords:

comment:6 Changed 4 years ago by Jun Omae

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

comment:7 Changed 4 years ago by Peter Suter

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 4 years ago by Peter Suter (previous) (diff)

comment:8 Changed 4 years ago by Jun Omae

Milestone: 1.0.31.0.4

comment:9 Changed 4 years ago by Ryan J Ollos

Milestone: 1.0.41.0.5

comment:10 Changed 4 years ago by Jun Omae

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.

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

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.

comment:12 in reply to:  11 Changed 4 years ago by Jun Omae

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 Changed 4 years ago by Jun Omae

Milestone: 1.0.51.0.6

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

comment:14 Changed 4 years ago by Jun Omae

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

comment:15 Changed 4 years ago by Jun Omae

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