Bug 331793 - [Search][File] Need option to search only shared files (i.e. stored in SVN, git, etc)
Summary: [Search][File] Need option to search only shared files (i.e. stored in SVN, g...
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Team (show other bugs)
Version: 3.6.1   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform Team Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-03 12:57 EST by Yegor Jbanov CLA
Modified: 2019-09-06 16:14 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yegor Jbanov CLA 2010-12-03 12:57:39 EST
Build Identifier: 20100917-0705

Problem
-------

As of today any search for a file will look into svn-ignored files and folders. However, a lot of svn-ignored files are large/obscure/auto-generated/frequently-out-of-sync and in most cases I don't want to search in those files, because:

- They only add clutter to my search results and no value
- They increase the amount of time and RAM necessary to perform the search

Solution
--------

Provide a new check-box in Eclipse's [Search][File] dialog:

[x] Search shared files only

When selected, Eclipse will search through all files except those that are explicitly ignored by the SCM (through svn:ignore and the like).

Reproducible: Always

Steps to Reproduce:
1. Go to Search => File
2. Enter any search criteria
3. Observe the lack of option to "Search shared files only"
4. Click "Search"
5. Observe that svn-ignored files are included in search results
Comment 1 Tomasz Zarna CLA 2010-12-06 05:41:49 EST
Sounds reasonable, but isn't it more an enhancement request for Platform/Search? I can imagine a new checkbox in TextSearchPage that would make the search confirm with Team.isIgnoredHint(IResource)[1] whether a resource should be included in the scope.

[1] note that Team.isIgnoredHint(IResource) first checks if a given resource is derived
Comment 2 Dani Megert CLA 2010-12-06 05:50:07 EST
(In reply to comment #1)
> Sounds reasonable, but isn't it more an enhancement request for
> Platform/Search? I can imagine a new checkbox in TextSearchPage that would make
> the search confirm with Team.isIgnoredHint(IResource)[1] whether a resource
> should be included in the scope.

The problem is that Search does not depend on Platform Team (and that should no change). Platform Resources already has some Team related knowledge (org.eclipse.core.resources.IResource.TEAM_PRIVATE). If it would also know about ignored resources then Search could do what you suggest.
Comment 3 Markus Keller CLA 2010-12-06 09:26:55 EST
See also bug 244968 and bug 37534. Yegor, a workaround could be to mark the files as derived and then make sure the checkbox is cleared on the File Search tab.
Comment 4 Yegor Jbanov CLA 2010-12-06 11:25:18 EST
Thanks, Markus. I'll take a look at the "Derived" option. I never realized it was there.

I agree that Search should not have a dependency on Team. However, it would still work if the dependency went the other way - if Team had a dependency on Search. Search could allow third-party plugins register custom search filters. Team would then install a Search filter for ignoring certain files based on Team properties.
Comment 5 Dani Megert CLA 2010-12-06 12:07:13 EST
(In reply to comment #4)
> Thanks, Markus. I'll take a look at the "Derived" option. I never realized it
> was there.
> 
> I agree that Search should not have a dependency on Team. However, it would
> still work if the dependency went the other way - if Team had a dependency on
> Search. Search could allow third-party plugins register custom search filters.
> Team would then install a Search filter for ignoring certain files based on
> Team properties.

Sure, but in this case it might be easier to just add the ignored team resources knowledge to the Resources plug-in.
Comment 6 Eclipse Webmaster CLA 2019-09-06 16:14:42 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.