I would be good to add support to issues.roundup-tracker.org to
automatically create links in msgs to commits in the Mercurial repository.

Some initial discussion has be started at:
  http://sourceforge.net/mailarchive/message.php?msg_id=29733347

Some info gleaned from the email list so far...

Matching of commit IDs should include (with optional 'hg:' prefix):
 * 12 character hex string surrounded by whitespace
 * 40 character hex string surrounded by whitespace

So the following:
 * <some text> baddbae588ad <more text>
 * <some text> baddbae588ad85d12ac3868415631e3cbd34d865 <more text>
 * <some text> hg:baddbae588ad <more text>
 * <some text> hg:baddbae588ad85d12ac3868415631e3cbd34d865 <more text>

Should link to:
  http://roundup.hg.sourceforge.net/hgweb/roundup/roundup/rev/baddbae588ad


Other things to consider:
 * should we worry about case-insensitive matching?
 * links to repository tags
 * links to repository revision numbers
 * links to specific files/lines

> * should we worry about case-insensitive matching?

hgweb seems to accept only lowercase cs ids, so the regex can be limited
to [0-9a-f].  OTOH cs ids are lowercase everywhere so someone would have
to intentionally convert it to uppercase to break the link.

> * links to repository tags

I would do this only if prefixed by 'hg:'.  hgweb accepts tags already,
so you don't have to anything special to handle this (just have a regex
that accepts the tags).

> * links to repository revision numbers

Revision numbers (the sequential ones) shouldn't be used IMHO.

> * links to specific files/lines

I find this handy, so you could include it too.

>> * should we worry about case-insensitive matching?
>
> hgweb seems to accept only lowercase cs ids, so the regex can be limited
> to [0-9a-f].  OTOH cs ids are lowercase everywhere so someone would have
> to intentionally convert it to uppercase to break the link.

Yes, this makes sense. It might also reduce false-positives slightly.

>> * links to repository tags
>
> I would do this only if prefixed by 'hg:'.  hgweb accepts tags already,
> so you don't have to anything special to handle this (just have a regex
> that accepts the tags).

Agreed. I was thinking that all links would be prefixed by 'hg:' with 
the exception of the 12/40 character commit IDs (which would be optional)

>> * links to repository revision numbers
>
> Revision numbers (the sequential ones) shouldn't be used IMHO.

Because we would be only linking to a specific repository branch, 
linking of revision numbers _should_ be safe, but I am happy to leave 
them out. If someone specifically requests the feature later, then we 
can look it again in the future.

>> * links to specific files/lines
>
> I find this handy, so you could include it too.

I am thinking a scheme like:
   hg:<commit ref>:path/to/file

 From a little bit of experimenting it seems as though the <commit ref> 
can be a commit ID, tag, branch, or revision ID. It would also support 
adding '#l<line no>' to the end without requiring anything extra to be done.

Other suggestions welcome though.

> I am thinking a scheme like: hg:<commit ref>:path/to/file

For the Python bug tracker we just support path/to/file and
path/to/file:xxx, where xxx is the line number.  We also support that
for tracebacks.  We have no way to select the cs id/branch, even if
there is an rfe for branch support somewhere.

What I tried to do was to write regexes that matched what people were
already using, rather than having people using some specific markup to
create links.

> For the Python bug tracker we just support path/to/file and
> path/to/file:xxx, where xxx is the line number.  We also support that
> for tracebacks.  We have no way to select the cs id/branch, even if
> there is an rfe for branch support somewhere.

Do you check that the 'path/to/file' starts with a certain directory 
(ie. 'path/') or do you just match string of text that has '/'s in it? 
If you just match text that has '/'s, then I imagine it could result in 
quite a few false positives.

This should be less of an issue for matching with a line number.

Links that don't include a revision id (ie. link to tip) may become less 
relevant over time though as code changes.

> Do you check that the 'path/to/file' starts with a certain directory 
> (ie. 'path/') or do you just match string of text that has '/'s in it? 

The former, see:
http://hg.python.org/tracker/python-dev/file/1aa80c5bbd48/extensions/local_replace.py#l86
We also highlight paths in tracebacks (using a different mechanism, see
line 92).

> Links that don't include a revision id (ie. link to tip) may become
> less relevant over time though as code changes.

This is true, but usually
1) once the issue is closed the link will be rarely used;
2) even if the code changes it's usually trivial to find the change;

This is especially true if the issue includes the changeset of the fix
that links to the diff of what got changed.  In addition, if people
mention a specific file they might include the full path, but it's
unlikely that they will add other markers unless they are aware they
exist and they remember/know how to use them.

I designed the replacements in that file based on real-world examples I
saw on the tracker, and improved them whenever I found something that
wasn't converted in a link (or wasn't converted correctly).

Completed with hg4972:f87c0cca37ae there are links to our repo.

See 
https://sourceforge.net/p/roundup/code/ci/default/tree/website/issues/extensions/local_replace.py
for the allowed values.

revf87c0cca37aebcd70035b872a6cf21faae7f78e2 should also work.

Is this enough to close this issue?

No response for 6 month, assuming that the current situation is good
enough (for our tracker). Thus closing.

However it would make sense to add some more instructions and patterns
somewhere how to link typical repos to get this nice integration more
usage from roundup people.