add alternatives for changeset links

[Waldemar Kornewald <wkornewald>]

On our site, many people don't use the "r123" scheme to refer to a certain revision. Many of them write "rev123", "rev 123", "revision 123", or even "Revision 123". It would be nice if this were supported, too.

[Emmanuel Blot]

I really don't see this implemented in Trac core, but it could be done through a plugin:

1. this could lead to opposite opinions, other users would like to get rid of this feature
2. from a more general perspective, this can create boring false-positive links
3. this one is personal but I think it's better to educate users to use defined conventions rather than promote proliferation of custom syntaxes

A good start point to write such a plugin might be the emoticon plugins, such as the ones from cmlenz and cboos, see ​http://trac-hacks.org.

Propose as wontfix.

[Waldemar Kornewald <wkornewald>]

I think there is a good reason for having that feature in core: you can't educate new users all the time. I also don't think that false-positives would be such a big problem.

[Emmanuel Blot]

Replying to Waldemar Kornewald <wkornewald>:

I think there is a good reason for having that feature in core: you can't educate new users all the time. I also don't think that false-positives would be such a big problem.

Knowing that even 'r123' has been one of them with some kind of repositories, I think it could ;-)

Anyway, this does not justify to implement this feature in the core, IMHO.

[Waldemar Kornewald <wkornewald>]

This is defensive design. You make the software understand the user even when the user doesn't know the (artificial) conventions. I really don't understand why we should enforce conventions on users that are absolutely not obvious. Many people only know the word "revision" and thus write something like "I think you introduced a bug in revision 123." I'm not making this up. We have this on ​our Trac instance. While I could teach most of our developers to stick to the conventions I can't and don't want to tell every bug reporter who doesn't use our conventions what the correct syntax is and I don't think that any other project will want to do it.

Of course, this could be part of a plugin, but something like this makes sense to have on all sites, so users can write the way they know and Trac still understands them. In the end, our developers profit from this. The few false positives don't hurt anyone because you don't have to click on them.

[Emmanuel Blot]

Replying to Waldemar Kornewald <wkornewald>:

This is defensive design. You make the software understand the user even when the user doesn't know the (artificial) conventions.

My point is that Trac targets developers, this is not Wikipedia: I'd rather go for naming conventions than heuristics to wikify developers' comments.
Another developer may write "in version 123" instead of "revision 123", the next one may write "in release 123", etc. Where do you set the limit.

Of course, this could be part of a plugin, but something like this makes sense to have on all sites,

Definitely not.
If this is to be implemented in the core, there should be an option to disable this magic behaviour. This is going to generate false positives (for ex: "in this revision 2 new tests have been added"), which I really won't like on our systems.

[Christian Boos]

Replying to Waldemar Kornewald <wkornewald>:

… we have this on ​our Trac instance.

… as can be seen from the link above, you're not even using Trac for browsing the repository, but rather linking to ViewSVN. Do you think that should be made an option in Trac itself as well? Probably not. We can't possibly deal with all customizations wishes, that's why we have plugins in the first place. Besides, I agree with eblot about the unexpected surprises this change would have.

OTOH, your use case makes for a nice example of a IWikiSyntaxProvider plugin, see r5207.

(P.S: out of curiosity, is there a specific feature lacking in TracBrowser or some limitation that made you prefer using ViewSVN instead?)

[Emmanuel Blot]

fixed? I assume this is a 'typo'

[Christian Boos]

Well, r5207 is a code change… but yes, wontfix in the sense that this won't go in the core.

[Waldemar Kornewald <wkornewald>]

Replying to cboos:

… as can be seen from the link above, you're not even using Trac for browsing the repository, but rather linking to ViewSVN. Do you think that should be made an option in Trac itself as well? Probably not.

Of course it shouldn't. :)

OTOH, your use case makes for a nice example of a IWikiSyntaxProvider plugin, see r5207.

Thanks for that!

(P.S: out of curiosity, is there a specific feature lacking in TracBrowser or some limitation that made you prefer using ViewSVN instead?)

Our repository is hosted at berlios.de and AFAIK Trac doesn't yet support remote repositories.

[Waldemar Kornewald <wkornewald>]

Replying to eblot:

Replying to Waldemar Kornewald <wkornewald>:

This is defensive design. You make the software understand the user even when the user doesn't know the (artificial) conventions.

My point is that Trac targets developers, this is not Wikipedia: I'd rather go for naming conventions than heuristics to wikify developers' comments.

If Trac targets developers then you really don't care about a lot of bug reporters. While your Trac instance might only get used by developers there are other open-source projects that target end-users and they depend on users reporting bugs. This means that users should feel as comfortable as possible and get a very easy to use reporting tool that is forgiving when they make "mistakes". I hope you do care about other open-source projects and agree that open-source projects need usability-oriented tools if they want to be competitive with commercial alternatives.

Another developer may write "in version 123" instead of "revision 123", the next one may write "in release 123", etc. Where do you set the limit.

Both terms would be plain wrong while the other ones are abbreviations of "revision". That's where I set the limit in my plugin.

Of course, this could be part of a plugin, but something like this makes sense to have on all sites,

Definitely not.
If this is to be implemented in the core, there should be an option to disable this magic behaviour. This is going to generate false positives (for ex: "in this revision 2 new tests have been added"), which I really won't like on our systems.

Well, I can't do anything about it. To me, the few false positives don't matter (and could be worked around by putting a comma after "revision" or writing "two") because it's much more important to our bug reporters feel comfortable.

Well, you seem to disagree and I can continue to use my own module. This was just a suggestion to improve usability.

[Christian Boos]

Replying to Waldemar Kornewald <wkornewald>:

Replying to cboos:

(P.S: out of curiosity, is there a specific feature lacking in TracBrowser or some limitation that made you prefer using ViewSVN instead?)

Our repository is hosted at berlios.de and AFAIK Trac doesn't yet support remote repositories.

OK, I see, that's a valid excuse ;-)

If they're running Subversion 1.4, you can eventually set up a mirror using svnsync (See #493 for details).

[Emmanuel Blot]

Replying to Waldemar Kornewald <wkornewald>:

Both terms would be plain wrong while the other ones are abbreviations of "revision". That's where I set the limit in my plugin.

I don't see how "end-users" (quoting) would have to care about the SVN terminology, as 'revision' is not universal in SCM world.

To me, the few false positives don't matter (and could be worked around by putting a comma after "revision" or writing "two")

How end-users would know this as the purpose of this enhancement is to help users not boring about naming conventions?

What I meant here is that I'm not sure to fully understand your point: on one hand, this enhancement is about letting users write natural language reports, while OTOH they would nevertheless have to care about the syntax (to avoid false positive, and to trigger the expected wikification with defined keywords).

I think I understand what you mean (and like to see implemented), but my point here is that it does not seem to be a mainstream feature, so the plugin way would probably be a better solution.

[Matthew Good]

STOP!

I'm going to have to kill this discussion here since we're going in circles. If you'd like to continue please move the discussion to the trac-dev MailingList.

@cboos, eblot: I think we need to try to limit the amount of back-and-forth on the ticket discussions. This makes it really hard for people to tell the current situation since there's a lot of debate to read through. If it looks like a discussion is starting to drag on please ask the participants to move it to the MailingList. We can of course link to the thread, then when some decisions have been made we can summarize them in the ticket.