With ClearCase, you can check whether a branch type exists by executing:
cleartool lstype -kind brtype -invob my_vob
... but - this tends to take a lot of time (server load? many branch types?). Is there a faster way to check whether a specific branch type exists or not?
You can try, to see if this is quicker, a cleartool describe
cleartool describe brtype:aBranch#/vobs/avob
# or, for Windows
cleartool describe brtype:aBranch#\avob
The idea is: if it fails, the branch does not exist.
Actually, you can get what you want using lstype too. Suppose you're interested in a branch named my_branch and your VOB is located at /path/to/my_vob:
cleartool lstype brtype:my_branch#/path/to/my_vob
If you need to know if a global type is instantiated, use:
cleartool lstype -local brtype:my_branch#/path/to/my_vob
Related
I keep getting the error below when I use dbt run - I can't find anything on why this error occurs or how to fix it within the dbt documentation.
[WARNING]: Did not find matching node for patch with name 'vGenericView' in the 'models' section of file 'models\generic_schema\schema.sql'
did you by chance recently upgrade to dbt 1.0.0? If so, this means that you have a model, vGenericView defined in a schema.yml but you don't have a vGenericView.sql model file to which it corresponds.
If all views and tables defined in schema are 1 to 1 with model files then try to run dbt clean and test or run afterward.
Not sure what happened to my project, but ran into frustration looking for missing and/or misspelled files when it was just leftovers from different compiled files not cleaned out. Previously moved views around to different schemas and renamed others.
So the mistake is here in the naming:
The model name in the models.yml file should for example be: employees
And the sql file should be named: employees.sql
So your models.yml will look like:
version: 2
models:
- name: employees
description: "View of employees"
And there must be a model with file name: employees.sql
One case when this will happen is if you have the same data source defined in two different schema.yml file (or whatever you call it)
I have a fork in github. I am able to install target like this in npm
"my-fork-of-a-package": "github:my-profile/my-fork-of-a-package#branch"
in package.json. However I am unable to target a tag of the branch or a version number.
I'm looking for a some kind of #version or #tag or #commitHash syntax.
Something kinda like this - except for that this doesn't work.
'"my-fork-of-a-package": "github:my-profile/my-fork-of-a-package#branch#version"
You can do this by using the #semver:<semver> notation like so:
"my-fork-of-a-package": "github:my-profile/my-fork-of-a-package#semver:v1.0.27"
see https://docs.npmjs.com/cli-commands/install
Your question is tricky for a potential answer because generally, a branch implies the version number.
As per docs:
npm install gitlab:<gitlabname>/<gitlabrepo>[#<commit-ish>]:
Install the package at https://gitlab.com/gitlabname/gitlabrepo by
attempting to clone it using git.
If # is provided, it will be used to clone exactly that
commit. If the commit-ish has the format #semver:,
can be any valid semver range or exact version
https://docs.npmjs.com/cli/install
Why don't you simply consolidate on only one level (branch1-v1, branch1-v2,branch2-v1...)?
You can effectively call a #branch, so i think it would be safe for you to rename & update your data structure to be 1 big pool with specific names.
That way, you'll be able to call the specific package/git through #branch1{your-own-separator}version-X.X
TL;DR:
Add tags in name, will look messy but that's why search/indexes exist.
I need to set variables in root scope in one job to be used in a different job. The first job has a Javascript job entry, with the statements:
parent_job.setVariable("customers_full_path", "C:\\customers22.csv", "r");
true;
But the compilation fails with:
Couldn't compile javascript:
org.mozilla.javascript.EvaluatorException: Can't find method
org.pentaho.di.job.Job.setVariable(string,string,string). (#2)
How to set a variable at root level in a Javascript job entry?
Sorry for the passive agressive but:
I don't know if you are new to Pentaho but, the most common mistake for new users, with previous knowledge of programming, is to be sort of 'addicted' to know methods, as such you are using JavaScript for a functionality that is built in the tool. Both Transformations(KTR) and JOBs(KJB) have a similar step, you can better manipulate this in a KTR.
JavaScript steps slow down the flow considerably, so try to stay away from those as much as possible.
EDIT:
Reading This article, seems the only thing you're doing wrong is the actual syntax of the command..
Correct usage :
parent_job.setVariable("Desired Value", [name_of_variable]);
The command you described has 3 parameters, when it should be 2. If you have more than 1 variable you need to set, use 3 times the command. Try it out see if it works.
I accidentally updated to a previous revision, and committed from it under the default branch, causing 2 heads under the default branch. I want to move one of the heads to another branch. This head I want to move was made a couple transactions ago. How can I change the branch it is a part of so that I can push the other head to the server without a force push?
I have not pushed anything to the server so far. If it comes down to it, I can copy the files I need and reclone the repository.
Rebase
Graft (move to new place) + Histedit (kill old changeset)
MQ, if you know it (convert cset to MQ-patch, update to new parent, qpop, qfinish)
You can rewrite the history with the rebase extension. It's already installed, you just need to enable it (from File > Settings > Extensions in tortoiseHG). Inside tortoiseHG you can find it if you right-click on a revision, go to "Modify History", and choose "rebase". But for more control I recommend dropping to the commandline.
Let's say you have a revision w that's a new head off the default branch. (w might have descendants which will move along with it).
-o-o-o-o
\
w
Its parent should have been some revision b in another branch (not shown). Just enter:
hg rebase --source w --dest b --detach
That's it! It will rebase w and all of its descendants (if any), so that its new parent is b. It will be assigned to the same branch name as b, unless you add --keepbranches. The flag --detach ensures that you don't end up with a complex topology under some circumstances.
I am trying to branch a file in ClearCase Remote Client.
I have the branch set up and the config spec is updated to handle the branch.
But I can't find the option, and the googling isn't helping much.
The way I understand your question, it sounds like you want to somehow select a command from a Clearcase RC menu(s) and have the branch explicitly created(?)
Clearcase has no explicit "Generate Branch for this File" command; you would want the "Checkout" command in this case. Branching is indirect and is a result of checking out a version of a file in a view that has a config spec with the '-mkbranch ' operation in it. I.e. the following config spec will create the dev_1.0_branch once I check it out (for any and all vobs and files):
element * CHECKEDOUT
element * .../dev_1.0_branch/LATEST
element * /main/LATEST -mkbranch dev_1.0_branch
The first line is standard for views in which you are doing development, line 2 will assure that I see any file that has a dev_1.0_branch (particularly important for the checkout+mkbranch to work as expected :-), and line 3 will select the latest version of any file that does not have a dev_1.0_branch and will create the branch if (and only if) the file version selected by that rule is checked out.
Please let me know if any of the above sounds greek to you, particularly any of the config spec rules. Having worked with ClearCase for a long time, I assume and use a lot of its terminology and concepts as if it's common knowledge :-P.
One thing of note: if you checkout the file, then immediately uncheckout the file, you will leave an empty branch on that file (i.e. in the above you would have a file with a version such as: foo.c##/main/dev_1.0_branch/0, but no /main/dev_1.0_branch/1 version). Many sites prefer to keep the version tree clean and remove empty branches (one can be found in this IBM Rational Technical article)
Just to be clear, I'm familiar with ClearCase Base & ClearCase MultiSite, but have not worked with the Remote Client yet.
--- 2009-Jun-29 Update
In response to Paul's comment below, if you want to be selective in what files are branched, you can modify the "*" to be more specific. For example, if you want to only branch foo.c in the FOODEV VOB, but leave everything else on main:
UNIX config spec:
element * CHECKOUT
element * .../my_dev_branch/LATEST
element /vobs/FOODEV/src/foo.c -mkbranch my_dev_branch
element * /main/LATEST
(For windows, you would want to use Windows conventions. I.e. \FOODEV\src\foo.c).
You can also select a directory and all elements below the directory (again UNIX config spec):
element * CHECKOUT
element * .../my_dev_branch/LATEST
element /vobs/FOODEV/src/mycomponent/... -mkbranch my_dev_branch
element * /main/LATEST
The main page for config_spec (cleartool man config_spec from the command line on windows or unix) provides decent guidance in the "Pattern" section for how to write the element/version selector (2nd column).
You can do a lot of complex version selection with the config specs. Please let me know if you would like more details or specifics.
Here's a config spec that I used for fixing a particular bug, with names changed to disguise some of the guilty.
element * CHECKEDOUT
element * .../TEMP.bugnum171238.jleffler/LATEST
mkbranch -override TEMP.bugnum171238.jleffler
include /clearcase/cspecs/project/version-1.23.45
To create the branch, in each VOB, I used a command:
ct mkbrtype -c 'Branch for bug 171238' TEMP.bugnum171238.jleffler#/vobs/project
Previously, we used config specs with -mkbranch rules appended to the various element lines.