Search for a revision/ticket/report number should find that changeset/ticket/report

[Markus Bertheau <twanger@…>]

e.g. when I input 614 in the search field, the changeset 614 should be among the top search results.

[cboos@…]

Near miss.

You need to enter [614] in the search field, and there you go.

See also #952.

[cmlenz]

Well, arguably we should still support searching just for the number... it wouldn't take you directly to the changeset page, but the results should include the changeset itself IMHO.

[cboos@…]

Well, why not the ticket 614 as well then... (and the report 614 :))

[cmlenz]

Right :-)

[pphaneuf@…]

I find it a bit odd that putting r614 in wiki formatted text (which is a bunch of places) will link to the changeset, but searching for the same doesn't work, I have to search for [614]. While I agree that just searching for 614 is a bit random (which of the ticket/changeset/report are you supposed to get), r614 is pretty intuitive (as well as very likely to be copy/pasted straight from other places, such as Subversion output in a terminal).

[cboos]

Replying to pphaneuf@gmail.com:

I find it a bit odd that putting r614 in wiki formatted text (which is a bunch of places) will link to the changeset, but searching for the same doesn't work,

Works like that in 0.10.

More precisely: any TracLinks entered in the quick search box will directly make you jump to the targeted resource. OTOH, if that TracLink is entered in the search box of the Search page itself, this will perform a search for that link and provide you with a link to that resource, on top of the other search results.

This ticket is about adding more "intelligence" to the search when entering a simple number.

[Pierre Phaneuf <pphaneuf@…>]

Already like that in 0.10? Excellent, I'll have to look into upgrading soon, then, particularly as 0.10 seems to be getting pretty close to release.

Thanks!

[cmlenz]

#3419 was marked as duplicate of this ticket.

[cboos]

#3856 marked as duplicate of this one as well.

[mgood]

r3857 adds search results for tickets and changesets based on their identifiers. There's currently no searching for reports, which I didn't add. Does it make sense to search for reports too? I can't imagine a project having enough reports that you'd need to search them. Anyone see a reason to include reports in the search results?

[cboos]

I'm not sure r3857 is really the adequate implementation for this feature...

First, you'll have the [search] min_query_length configuration option, usually set to 3, which will prevent you to search for changesets and tickets < 100 (and this is certainly problematic for tickets at least).

Then, for large projects, when you're looking for changeset 123, you don't necessarily want to get matches for r1123, r1231, r1232, r1233, ... , r2123, r3123 and so on...

Finally, with r3857, those results will now be placed among other results, not shown as special Quickjump targets, like suggested in #3419.

As an alternative implementation, I propose to extend the ISearchInterface to accept numerical searches. This could even in the future be extended to interval searches, which in the case of changesets would redirect you to the appropriate range.

[cboos]

Well, it's been one month now, still didn't get any feedback... so to put things straight: I'm strongly -1 on r3857 for the reasons explained above. Matt, can you please back out the change?

[mgood]

Replying to cboos:

Well, it's been one month now, still didn't get any feedback... so to put things straight: I'm strongly -1 on r3857 for the reasons explained above. Matt, can you please back out the change?

Well, I understood your points about how this could be better, but I don't see that change as being harmful in the meantime. Searching for "123" will already find other items which simply contain "123" in the text, such as a link to "r1234" or "r2123", so I don't think it's worse for those changesets to show up in the search results as well.

[cboos]

Replying to mgood:

.. Searching for "123" will already find other items which simply contain "123" in the text, such as a link to "r1234" or "r2123", so I don't think it's worse for those changesets to show up in the search results as well.

Well, the likeliness for getting many false positive is quite low in the above case, as not all changesets are linked to. With your changes, any 3-digit number will generate 20 false positive matches when you have 10k changesets and twice that number if you have also around 10k tickets. So those 40 results are always uninteresting, that's why I think it's better to leave them out. Now think about the people lowering the minimal number of characters allowed for search terms (korean sites, where most words are made of 2 characters) and you get even more uninteresting results (do the math ;) ).

[cboos]

See also SearchRefactoring#Directaccesstoresourcesbytheirnumbers1

[cboos]

There's also the problem reported in #7654, the limit on the number of characters prevents one to have direct access to some resources.

One solution would be to add a 3^rd method to the ISearchProvider interface (e.g. get_exact_matches), returning the exact matches only: for "1" the ticket search would return a link to ticket 1, the changeset search would return a link to changeset 1, etc.

This would even allow to generalize the "/jump_to_path" hack, as the browser module could then implement it.