Is it possible using .tfignore to add a wildcard to directories? I assumed it would have been a case of just adding an asterisk wildcard to the directory segment. For example:
\path\*\local.properties
However this does not work and I am unsure how I would achieve such behaviour without explicitly declaring every reference that I need excluding. .
Documentation
# begins a comment line
The * and ? wildcards are supported.
A filespec is recursive unless prefixed by the \ character.
! negates a filespec (files that match the pattern are not ignored)
Extract from the documentation.
The documentation should more correctly read:
The * and ? wildcards are supported in the leaf name only.
That is, you can use something like these to select multiple files or multiple subdirectories, respectively, in a common parent:
/path/to/my/file/foo*.txt
/path/to/my/directories/temp*
What may work in your case--to ignore the same file in multiple directories--is just this:
foo*.txt
That is, specify a path-less name or glob pattern to ignore matching files throughout your tree. Unfortunately you have only those two options, local or global; you cannot use a relative path like this--it will not match any files!
my/file/foo*.txt
The global option is a practical one because .tfignore only affects unversioned files. Once you add a file to source control, changes to that file will be properly recognized. Furthermore, if you need to add an instance of an ignored name to source control, you can always go into TFS source control explorer and manually add it.
It seems this is now supported
As you see I edited tfignore in the root folder of the project such that any new branch will ignore its .vs folder when being examined for source control changes
\*\.vs
Directory/folder name wildcarding works for me in VS2019 Professional. For example if I put this in .tfignore:
*uncheckedToTFS
The above will ignore any folder named ending with "uncheckedToTFS", regardless of where the folder is (it doesn't have to be top level folder, can be many levels deep).
Related
I'd like to overwrite admonition labels.
Admonitions are directives such as note, warning, and so on.
For Japanese, the labels are defined in
https://github.com/sphinx-doc/sphinx/blob/master/sphinx/locale/ja/LC_MESSAGES/sphinx.po.
Is there a simple way to overwrite them without changing the master repository?
Here is what works for me (tested with Sphinx 3.3.1):
Copy the Japanese sphinx.po from <sphinx_install_dir>/sphinx/locale/ja/LC_MESSAGES/
to <your_sphinx_proj>/locales/ja/LC_MESSAGES/.
Note the directory name locales (the default value of the locale_dirs configuration option).
Edit msgstr for the relevant entries (admonitions in this case) in the copy of sphinx.po.
It is not necessary to keep the entire copy. You can remove the unchanged entries if you want.
Run sphinx-build with language=ja (set it in conf.py or on the command line). A local project-specific sphinx.mo file is generated and used in the build.
This means that there will be two *.mo files for the same domain ("sphinx"). The local sphinx.mo is consulted first, and the original sphinx.mo that comes with Sphinx is used as the fallback.
We're having a system uploads log files into a folder which named by date. It looks like:
/logs
/20181030
/20181031
/20181101
/20181102
/...
Suppose that I want to track the log files which produced during November by using spoolDir, How could I do this ?
#this won't work
a1.sources.r1.spoolDir = /logs/201811??
#this seems only works with files. Is it possible to filter folders here?
a1.sources.r1.includePattern = ^.*\.txt$
Acoording to the flume source code, folders that match the ignorePattern are skipped while recursing the folder tree(to register folder trackers). So you can ignore the folders which don't match your criteria. ^(?!201811..).*$ would exclude all the folders that are not folders of November 2018. Other folders will not be tracked.
But this pattern will also apply to file names. So any file with name that does not match ^201811..$ will also be ignored. You can add the ^.*\.txt$ pattern (the one you are using for the include pattern) to the regex to make flume accept your input files.
a1.sources.r1.ignorePattern = ^(?!(201810..)|(.*\\.txt)).*$
would do the trick for you.
please take a look at the bin-win target in my repository here:
https://github.com/thinlizzy/bazelexample/blob/master/demo/BUILD#L28
it seems to be properly packing the executable inside a file named bin-win.tar.gz, but I still have some questions:
1- in my machine, the file is being generated at this directory:
C:\Users\John\AppData\Local\Temp_bazel_John\aS4O8v3V\execroot__main__\bazel-out\x64_windows-fastbuild\bin\demo
which makes finding the tar.gz file a cumbersome task.
The question is how can I make my bin-win target to move the file from there to a "better location"? (perhaps defined by an environment variable or a cmd line parameter/flag)
2- how can I include more files with my executable? My actual use case is I want to supply data files and some DLLs together with the executable. Should I use a filegroup() rule and refer its name in the "srcs" attribute as well?
2a- for the DLLs, is there a way to make a filegroup() rule to interpret environment variables? (e.g: the directories of the DLLs)
Thanks!
Look for the bazel-bin and bazel-genfiles directories in your workspace. These are actually junctions (directory symlinks) that Bazel updates after every build. If you bazel build //:demo, you can access its output as bazel-bin\demo.
(a) You can also set TMP and TEMP in your environment to point to e.g. c:\tmp. Bazel will pick those up instead of C:\Users\John\AppData\Local\Temp, so the full path for the output directory (that bazel-bin points to) will be c:\tmp\aS4O8v3V\execroot\__main__\bazel-out\x64_windows-fastbuild\bin.
(b) Or you can pass the --output_user_root startup flag, e.g. bazel--output_user_root=c:\tmp build //:demo. That will have the same effect as (a).
There's currently no way to get rid of the _bazel_John\aS4O8v3V\execroot part of the path.
Yes, I think you need to put those files in pkg_tar.srcs. Whether you use a filegroup() rule is irrelevant; filegroup just lets you group files together, so you can refer to the group by name, which is useful when you need to refer to the same files in multiple rules.
2.a. I don't think so.
I have a project in TFS with branches and I want to ignore some folders in each branch.
So I try this to ignore all branches folders, but it's not working:
\Tools\Web\APPREPORTS\Branches\*\node_modules\
\Tools\Web\APPREPORTS\Branches\*\packages\
So it's forcing me to do that in this way, specifing each branch:
\Tools\Web\ALMAREPORTS\Branches\DEV\node_modules\
\Tools\Web\ALMAREPORTS\Branches\DEV\packages\
\Tools\Web\ALMAREPORTS\Branches\STAGE\packages\
\Tools\Web\ALMAREPORTS\Branches\STAGE\node_modules\
\Tools\Web\ALMAREPORTS\Branches\PRODUCTION\packages\
\Tools\Web\ALMAREPORTS\Branches\PRODUCTION\node_modules\
There is another way to simplify that?
Thanks in advance.
Your method is not supported.
The * and ? wildcards are supported in the leaf name only.
More detailed info from this answer: tfignore wildcard directory segment
It depends which folder you put your .tfignore file in.
You can just use \node_modules to ignore all files in this folder.
The following rules apply to a .tfignore file:
# begins a comment line
The * and ? wildcards are supported.
A filespec is recursive unless prefixed by the \ character.
! negates a filespec (files that match the pattern are not ignored)
Source: MSDN Documentation
Use two asterisks:
\Tools\Web\APPREPORTS\Branches\**\node_modules\
\Tools\Web\APPREPORTS\Branches\**\packages\
Is there any importance of order of paths exists in dcc32.cfg? can we modify the order or can add some more paths to it as per our convenience?
Actually I have list of programs which are interdependent and I compile all of them using command line compiler.
So in this process does it checks order of path as well? Also found some of the paths missing from dcc32.cfg and I think adding them back can solve my problem.
The order of the directories in a search path does matter if the file being searched for is found in more than one of the directories. For example, consider this search path:
dir1;dir2
If the file being searched for is in both dir1 and dir2, then the version found in dir1 will be used, because it is found first.
On the other hand, if the search path was:
dir2;dir1
then the version in dir2 would be used.
So, you can modify the order, but it changes the meaning of the search. Whether this has material affect for you, only you can know.
And yes you can add more directories to the paths, which also changes the meaning. Again, only you can know whether or not changes you make are appropriate.