I have to do a major search-and-replace update across multiple repos...
In my initial search, I get back over 30,000 results. Many of these results are inconsequential and shouldn't be touched because they are 3rd-party tools. Most of these tools are ignored in the repos by .gitignore.
So, I tried creating a new Search Scope which could include only non-.gitignored files only to find I must manually select all folders...
...or must I?
Is there a way to create a scope or otherwise search only non-.gitignored files?
NOTE: Do not confuse my request with PhpStorm/Intellij's "ignore" feature. I am specifically asking about .gitignore.
Related
My VSCode extension creates a database of symbols and stores it along the project. I'd like to automatically exclude this file from search results (it would be even better to exclude it from file explorer).
Is there a way how can I modify "search.exclude" from my extension or can I set such a setting in my extension's package.json?
There is no API for you to contribute to search.exclude and/or files.exclude settings, so you are out of luck on this.
On the other hand, you can make your extension to update the User Settings using workspace.getConfiguration("section").update("section") API. With that, search.exclude and/or files.exclude settings could de updated to respect the symbols you want to be ignored.
But, I would suggest you to warn the users about this process, asking for their approval, before effectively updating the setting. Personally, I don't do this, and prefer that extensions that don't do this as well, but I understand sometimes this is necessary/inevitable.
Hope this helps
Are there guidelines regarding how to share a Snakemake workflow among multiple users on the same data under Linux, or is the whole thing considered bad practice?
Let me explain in case it's not clear:
Suppose user A executes a workflow in directory dir/. Assume the workflow terminates successfully, and he/she then properly sets file/directory permissions recursively on all output and intermediate files and the .snakemake/ subdirectory for other users to read/write, of course.
User B subsequently navigates to dir/, adds input files to the workflow, then executes it. Can anything go wrong?
TL;DR: I'm asking about non-concurrent execution of the same workflow by distinct users on the same system, and on the same data on disk. Is Snakemake designed for such use cases?
It's possible to run snakemake --nolock which will prevent locking of the directory, so multiple runs can be made from inside the same directory. However, without lock, there's now an opening for errors due to concurrent runs trying to modify the same files. It's probably OK, if you are certain that this will be avoided, e.g. if you are in constant communication with another user about which files will be modified.
An alternative option is to create a third directory/path, and put all the data there. This way you can work from separate directories/path and avoid costly recomputes.
I would say that from the point of view of snakemake, and workflow management in general, it's ok for user B to add or update input files and re-run the pipeline. After all, one of the advantages of a workflow management system is to update results according to new input. The problem is that user A could find her results updated without being aware of it.
From the top of my head and without more detail this is what I would suggest. Make snakemake read the list of input files from a table (pandas comes in handy for this) or from some configuration file. Keep this sample sheet under version control (with git/github) together with the Snakefile and other source code.
When users update the working directory with new files, they will also need to update the sample sheet in order for snakemake to "see" the new input and other users will know about it via version control. I prefer this setup over dumping files in a directory and letting snakemake process whatever is in there.
My program deploys with a configuration option that I've chosen to expose as a feature. This option can be one of two values.
Each configuration changes a set of settings files. They have different input file names (for the sake of example, let's call it option1-config20-lv80.xml), but should be installed to the configuration directory as config20-lv80.xml. Each option has a prefix that should be stripped like that, which also means only one of these options can be selected for install at a time. However, even with conditions preventing the install of one feature when the other is selected, my output is littered with:
LGHT0204: ICE30: The target file 'config20-lv80.xml' is installed in 'path' by to different components... This breaks component reference counting.
How can I give my users the option to choose between these configuration options and get around my ICE30 issues without any negative side effects?
I saw an similar question answered, but I'm not 100% sure how to implement it in wix#, or if there are other ways open to me to achieve my goal without disabling ICE30 validation or creating 2 installers.
A bit rushed, have a look...
Milk & Honey Winnie: In cases like this I prefer to install both files with different names using two different components and then switch between them with an option shown in the application itself. On launch or in the preferences. Makes deployment simpler, it is already complex (section "The Complexity of Deployment"). The linked answer you refer to can work technically, as can more hacky approaches.
Alternatives: I have a long answer here on different ways to install settings files: Create folder and file on Current user profile, from Admin Profile ranging from eliminating the whole file and using internal defaults, to downloading settings files from the network or just relying on clouded web-service settings retrieval from a database. Not 100% match, but maybe give it a skim?
A related issue is when you have a settings file that regular users can't write to. This is a list of approaches for eliminating that condition: System.UnauthorizedAccessException while running .exe under program files.
Hello helpful persons,
I'm working with trying to set up some new branch structures in our companies codebase for organization and sanity purposes. True to form decision makers have changed their minds and want the structure to be changed a bit from what I already have in place. Not an over-the-top request though, because no one is yet using the new structure so I have "free reign".
I need to simply move these thousands of files in the containing branch directories (//depot/main/... and //depot/dev/... respectively) into a //depot/main/[product_name]/... structure etc. which I'm on board with and understand the advantages.
While opening the files from //depot/main/... for edit and move I see in my output that there are several warning messages:
warning: edit of deleted file
and
warning: move of deleted file
How can I tell perforce that I do not want to open deleted files for edit, and in turn that I do not want to move deleted files to the new location(s)?
I have a feeling that there is some documentation that I am either not understanding or not finding properly.
Generally you only get that particular warning if you aren't synced to head and are trying to move a file. Make sure you are synced to the head revisions.
As suggested by raven you should probably be using integrate for this. Generally my recommendation is to use 'p4edit/p4 move' intra-branch and 'p4 populate/integ/copy/merge' for interbranch branch integrations.
I need to find out that how many times and which files are fixed or changed due to a bug between two specific dates in an open source project which uses Trac. I selected Webkit project for that purpose. (https://trac.webkit.org/) However, it can be any open source project.
What can I do for that? How do I start? Do i have to use version control systems like svn or git for intergration? I am kinda newbie for these bug-tracking and issue-tracking systems.
I'm not certain I exactly understand your question, but...
If you browse to the directory containing the files you care about in the Trac site, then click on Revision Log, you will get a list of changesets that affected that directory. You can select the revisions that span the timeframe of interest and then View changes and you will get a summary of the changes, and depending on the size of the changes and the particular Trac configuration, you may get the diffs on that page as well.
Now, that won't tell you how many times those files were changed, just the net changes.
It also won't tell you which bugs those changes were for.
If you really need to filter on what bug, you'll have to determine how that information is tracked by the particular project; and some might not track it directly. The project might include a #123 in the commit message. If you can rely on that, you could use svn log --xml {2009-11-01}:{2009-12-01} ... to get an xml version of the commit log which you could then parse and filter based on the presence of the bug's ticket number in the commit message. From that, you should have a list of the revisions that you care about.