Edgewall Software
Modify

Opened 17 years ago

Last modified 9 years ago

#6009 new enhancement

colons in revision identifiers

Reported by: thomas.moschny@… Owned by:
Priority: low Milestone: next-major-releases
Component: version control Version: devel
Severity: normal Keywords: revision link verify
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

At least for, but not limited to source:path@rev links, it would be nice to have support for revision identifiers that contain a colon, as such identifiers are common for some non-svn version control systems, e.g. mercurial or monotone.

However, looking at trac/versioncontrol/web_ui/browser.py, a colon separates the revision identifier from a line number mark (what is a "line number mark"? - this is not covered by TracLinks).

Additionally, in revision log or diff links, a colon is used to separate the start and end revision identifier.

So, it seems a colon cannot be used literally in a revid. Would it be possible to get some support for escaping such special characters in revision identifiers?

Attachments (0)

Change History (7)

comment:1 by Christian Boos, 17 years ago

Can you give an example for Monotone usage? In mercurial, in a revision of the form num:hash, num and hash are identifying unambiguously the same revision, so while it's often informative to see both of them, when referring to a changeset, either one of them is enough (hash form often preferred over the sequence number, though). I've not yet heard anyone complain about that on the mercurial side, so I'm interested to know more about the Monotone use case In bzr, I know that the rev needs to be completed with a branch name, is it the same situation?

in reply to:  1 comment:2 by thomas.moschny@…, 17 years ago

Replying to cboos:

Can you give an example for Monotone usage? In bzr, I know that the rev needs to be completed with a branch name, is it the same situation?

No. The point is that we'd like to expose as much as possible of Montone's selectors.

Especially such simple selectors like t:tag for specifying the revision carrying a certain tag or h:branch for the head of a branch are expected by the users to work within TracLinks, as long as they identify single unique revisions.

comment:3 by njs@…, 17 years ago

Right, in monotone, pretty much anywhere you can put a revision id, you can also put a selector. So e.g. on the command-line for cvs you can pick a revision by saying '-r <revid>', '-t <tag>'; in monotone, we just have '-r', and you can say any of '-r 30aed1', '-r t:mytag', '-r h:mybranch'.

An example might help. The specific use case where this came up is at http://partiwm.org/wiki/WikiStart, where I tried to write:

  * Latest version: [http://.../parti-0.0.1.tar.gz 0.0.1], ([source:NEWS@t:parti-0.0.1 NEWS])

The URL http://partiwm.org/browser/NEWS?rev=t:parti-0.0.1 does in fact work, but the above wikicode results in a link to http://partiwm.org/browser/NEWS?rev=t, instead.

I'm not sure what the right fix here would be — just unconditionally allow colons as part of revnos? (Perhaps breaking existing links that use them for the mysterious "line number marks"?) Let the VC backend tweak the TracLink syntax?

The more problematic case is for revision spans, as used by log: or diff: links. It would be nice if there were some way to link to the change between two releases, for instance — diff:t:parti-0.0.1,t:parti-0.0.2 or whatever — but I doubt any SVN users would appreciate losing that colon, since it's the same syntax as used by SVN itself.

comment:4 by Christian Boos, 16 years ago

Component: generalversion control
Keywords: revision link added
Milestone: 1.0
Owner: changed from Jonas Borgström to Christian Boos

comment:5 by Christian Boos, 14 years ago

Milestone: 1.0unscheduled

Milestone 1.0 deleted

comment:6 by Christian Boos, 14 years ago

Keywords: verify added
Milestone: triagingnext-major-0.1X
Priority: normallow

We should have a syntax that supports Mercurial 1.6 revsets also.

comment:7 by Ryan J Ollos, 9 years ago

Owner: Christian Boos removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


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