For configuration of streams in Perforce, there exist five access types (according to documentation, in order more-to-less-inclusive): share, isolate, import/import+, exclude. They are placed in the configuration line-by-line, like so:
share folder1/...
isolate folder2/...
Is it possible to override the access to a subfolder? Like so:
share folder/...
isolate folder/subfolder1/...
In the way that, folder/subfolder1/... will be isolate-d, but folder/subfolder2/... and all others will be share-d? It seems like a lot of manual work to include all separate subfolders otherwise, especially if they are added as development progresses.
If this works, what are the rules? Do later lines override earlier lines?
Or do more restrictive access lines override less restrictive ones (i.e. can share parent folder, isolate child folder, but not other way around)? E.g. is something like
exclude folder/...
share folder/subfolder1/...
also possible?
Let's try it out. If I change my stream Paths to:
Paths:
share folder/...
isolate folder/subfolder1/...
here's what I get when I try to merge a path that's inside the isolated folder and outside it:
C:\Perforce\test>p4 merge -n folder/subfolder1/...
folder/subfolder1/... - no target file(s) in branch view.
C:\Perforce\test>p4 merge -n folder/subfolder2/...
No such file(s).
which tells me that, indeed, subfolder1 is isolated correctly. The "no target files in branch view" error tells me that the path is excluded from the branch view (which is the function of isolate), whereas "no such file(s)" lets me know that the only reason there's nothing to merge is that I didn't bother to actually add any files there.
Let's try the other example and see how that works. After changing my Paths to:
Paths:
exclude folder/...
share folder/subfolder1/...
I can do a similar experiment with p4 sync:
C:\Perforce\test>p4 sync -n folder/subfolder1/...
folder/subfolder1/... - no such file(s).
C:\Perforce\test>p4 sync -n folder/subfolder2/...
folder/subfolder2/... - file(s) not in client view.
and that also works as I'd expect (basically the same way classic client views work) -- the later and more specific line overrides the earlier and more general line, so subfolder1 is shared while subfolder2 is excluded.
Related
Is there any way (for on premise github) to :
For N number of files in the Pull Request.
Look at the history of those files.
And add any/all github users (on the history) .. to the code reviewers list of users?
I have searched around.
I found "in general" items like this:
https://www.freecodecamp.org/news/how-to-automate-code-reviews-on-github-41be46250712/
But cannot find anything in regards to the specific "workflow" I describe above.
We can get the list of changed files to the text file from PR. Then we can run the git command below to get the list of users included in last version's blame. For each file we get from file list, run the blame command. This might be also simple script.
Generate txt file from list of files of PR.
Traverse all filenames through txt file. (python, bash etc.)
Run blame command and store in a list.
Add reviewers to the PR from that list manually or some JS script for it.
For github spesific: list-pull-requests-files
The blame command is something like :
git blame filename --porcelain | grep "^author " | sort -u
As a note, if there are users who are not available in github anymore. Extra step can be added after we get usernames to check whether they exist or not. (It looks achievable through github API)
We use Slurm workload manager to submit jobs to our high performance cluster. During runtime of a job, we need to copy the input files from a network filesystem to the node's local filesystem, run our analysis there and then copy the output files back to the project directory on the network filesystem.
While the workflow management system Snakemake integrates with Slurm (by defining profiles) and allows to run each rule/step in the workflow as Slurm job, I haven't found a simple way to specify for each rule, wether a tmp folder should be used (with all the implications stated above or not.
I am very happy for simple solutions how to realise this behaviour.
I am not entirely sure if I understand correctly. I am guessing you do not want to copy the input of each rule to a certain directory, do the rule, then copy the output back to another filesystem, since that would be a lot of unnecessary files moving around. So for the first half of the answer I assume before execution you move your files to /scratch/mydir.
I believe you could use the --directory command (https://snakemake.readthedocs.io/en/stable/executing/cli.html). However I find this works poorly, since then snakemake has difficulty finding the config.yaml and samples.tsv.
The way I solve this is just by adding a working dir in front of my paths in each rule...
rule example:
input:
config["cwd"] + "{sample}.txt"
output:
config["cwd"] + "processed/{sample}.txt"
shell:
"""
touch {output}
"""
So all you then have to do is change cwd in your config.yaml.
local:
cwd: ./
slurm:
cwd: /scratch/mydir
You would then have to manually copy them back to your long-term filesystem or make a rule that would do that for you.
Now if however you do want to copy your files from filesystem A -> B, do your rule, and then move the result from B -> A, then I think you want to make use of shadow rules. I think the docs properly explain how to use that so I just give a link :).
Issue: CODEOWNERS need fully qualified path for rule against a directory/subdirectory.
I am writing a sample CODEOWNERS below to show the problem.
* #global-owner
foo/bar/ #octocat
I am expecting that whenever a PR is raised for any file (even recursively) inside directory foo/bar, user should be assigned a review. However, this always defaults to the * rule.
However, when I change the file to something like this:
* #global-owner
/app/src/main/java/com/cueo/foo/bar/ #octocat
This works like a charm. But the problem with this is that I need to repeat each directory twice to something like this:
/app/src/main/java/com/cueo/foo/bar/ #octocat
/app/src/test/java/com/cueo/foo/bar/ #octocat
According to the documentation:
# In this example, #octocat owns any file in an apps directory
# anywhere in your repository.
apps/ #octocat
I believe this should work for a nested directory structure also, like:
foo/bar/apps/ #octocat
We need to prefix the paths with ** as well. This is not clear from the documentation.
So if we add a rule like:
* #global-owner
**/foo/bar/ #octocat
#octocat will be assigned for all foo/bar directories in the project.
My company has a local production server I want to download files from that have a certain naming convention. However, I would like to exclude certain elements based on a portion of the name. Example:
folder client_1234
file 1234.jpg
file 1234.ai
file 1234.xml
folder client_1234569
When wget is ran I want it to bypass all folders and files with "1234". I have researched and ran across ‘--exclude list’ but that appears to be only for directories and ‘reject = rejlist’ which appears to be for file extensions. Am I missing something in the manual here
EDIT:
this should work.
wget has options -A <accept_list> and -R <reject_list>, which from the manual page, appear to allow either suffixes or patterns. These are separate from the -I <include_dirs> and -X <exclude_dirs> options, which, as you note, only deal with directories. Given the example you list, something along the lines of -A "folder client_1234*" -A "file 1234.*" might be what you need, although I'm not entirely sure that's exactly the naming convention you're after...
I've been using unison as my file synchronizer of choice and life has been great.
Essentially I could modify any files on any side at any time without ever worrying who's master and slave, etc. It's bidirectional.
However with four roots failing over to each other when each's primary partner cannot be reached, I'm starting to push the limits of this tool. Conflicts arise that halt automatic syncing for the files involved. Aspects of my business logic are distributed across the different hosts, which modify sometimes the same files when run.
The merge option in the configuration file comes into play. It lets you specify different merge commands for different file types.
For example for log files only I like to interpolate their lines with:
merge = Name *.log -> diff3 -m CURRENT1 CURRENTARCH CURRENT2 > NEW || echo "differences detected"
Question: for *.last files only, what merge command would always favor the older copy?
For *.rb *.sh and other source files, I'm not looking to merge but always pick the newer version in case of conflicts. I can do that by default with the prefer = newer global option though.
For *.png files I typically prefer to keep the smaller(optimized) size.
Regarding the .rb and .sh files, you could use the preferpartial = Name *.rb -> newer and the same for .ssh files. For .last files, you can use older instead.
Regarding .png files, you could write your own merge command that checks the size of both files. I would then set merge = Name *.png -> mycmp CURRENT1 CURRENT2 NEW, and have the mycmp command takes three file path, compare the size of the first two, and copy it to the third path.