Ticket #3906 (reopened enhancement)
Opened 5 years ago
Last modified 19 months ago
Request for a files search (no indexing just plain find like search)
| Reported by: | sineer@… | Owned by: | cboos |
|---|---|---|---|
| Priority: | normal | Milestone: | next-major-0.1X |
| Component: | version control/browser | Version: | 0.10 |
| Severity: | normal | Keywords: | bitesized |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description
I would like a /usr/bin/find like file search to look for a specific filename in the repository recursively (ie, some*.pdf)
I've seen the RepoSearch? hack but I would like a simple file search (perhaps in Browse source or in Search directly with a files checkbox) that would let me search for a file or files in particular strictly based on the files in the repository.
This is a simple feature, I'm surprised it hasn't been implemented yet ;)
perhaps a simple hack would be in order...
Attachments
Change History
comment:1 in reply to: ↑ description Changed 5 years ago by cboos
- Milestone set to 0.11
comment:2 Changed 5 years ago by sineer@…
Sweet :)
Your right, it's probably not that simple to implement...
Thanks for the hard work! TRAC ROCK!!
comment:3 Changed 5 years ago by Noah Kantrowitz (coderanger) <coderanger@…>
- Resolution set to fixed
- Status changed from new to closed
This is now implemented in the Filename Search plugin.
comment:4 Changed 4 years ago by cboos
- Milestone 0.11 deleted
(not in trac core, so clearing the milestone)
comment:5 Changed 22 months ago by cboos
- Keywords bitesized added
- Resolution fixed deleted
- Status changed from closed to reopened
Would be nice to get this to work in a backend neutral way, as outlined in comment:1.
The filter itself could eventually be a tracopt. component but there will also probably be trac.versioncontrol.api changes that need to be done.
Nice bitesized feature for an upcoming release.
comment:6 Changed 19 months ago by rblank
- Milestone set to next-major-0.1X



Replying to sineer@gmail.com:
Perhaps because it's simpler to describe than to implement ;)
Looking in all files in the repository is out of question, as this would imply going recursively in the tree, which in case of Subversion is always something huge (due to the tag/branch by copying principle).
So we'd have to use the database, and the node_change table.
There, it's a bit better, as we will get the filenames, but we'd have to sort through the revisions to get the latest one (or the previous to last, in case the last is a Delete!). And that's not easily done for all backends, at least for now. See also #3837.
On the other hand, in Mercurial for example, you could simply search through the latest "manifest" (i.e. the list of all files).
But yes, it's a good idea.