I'm a new ClearCase user (woe is me...), on a Linux machine; I've been told to create a new branch time (to check my changes into), as preparation to creating my own view in which I'll make edits.
So, I ran
$ct mkbrtype foo -c "this is my new branch type"
to create my branch type. But - this gives me:
ct: Error: Unable to determine VOB for pathname ".".
My questions:
Why is this happening?
Do I need to create the view first? create and ct setview into it? Or - something else?
Try moving to the folder where your VOBs are mounted, e.g.
$ cd /path/to/vobs/
$ ct mkbrtype foo -c "this is my new branch type"
Created branch type "foo".
Hopefully that should be sufficient.
Hopefully that should be sufficient.
In addition of mkbrtype,here is what a dedicated view (dynamic if you want) would look like.
Simply modify your config spec for that new view with the right rules using your new branch: any new checkout will create the branch (mkbranch) automatically at the next checkout within that view.
element * CHECKEDOUT
element * .../myBranch/LATEST
element * /main/LATEST -mkbranch myBranch
element * /main/0 -mkbranch myBranch
element * /main/LATEST
Since you will do the checkout within /path/to/vobs/viewtag/path/to/file, you will be in the right vob for the branch to be created.
Related
I an new to ClearCase and started studying the ClearCase documentation.
UseCase : I have two branches - 'Branch_A' and 'Branch_B'.
I need to merge all my changes from 'Branch_A' to 'Branch_B'
I won't be able to use the ClearTeamExplorer, so only option is command line.
I read the documentation and its mentioned that cleartool findmerge command is the option for it.
But there is no direct example given for this.
Could someone please provide an command line example for this please?
Any help on this is appreciated.
Assuming a base ClearCase view/branch (no UCM views/Streams):
cleartool findmerge include a relevant example:
for the current directory subtree, compare versions visible in the current view against versions on another branch and perform any required merges.
cd /path/to/target/Branch_B/view
cleartool findmerge . –fversion /main/Branch_A/LATEST –merge –gmerge.
The idea is to be in the view set on the target branch, with a config spec ready to create new versions.
element * CHECKEDOUT
element * .../Branch_B/LATEST
element * /main/0 -mkbranch Branch_B
element * /main/LATEST -mkbranch Branch_B
The merge is done in the target view, on the target branch.
Now if you are using UCM, then the view done on a Stream has already the right config spec.
The idea remains the same: Execute the findmerge in the target view (after setting a dedicated activity, to record that merge)
In that case, check "How to merge changes from a specific UCM activity from one ClearCase stream to another"
You do not merge branches in UCM, you would merge UCM activities.
I need to create a new VOB and a branch to access the newly created VOB.
The development will not be on a main branch, so I create a release branch.
Once the development is done, the release branch will be merged to main branch.
How do I write a config spec for the initial branch so that it is derived of /main branch?
element /new_vob/... .../rel_branch/LATEST
mkbranch rel_branch
element /new_vob/... /main/0
end mkbranch rel_branch
Please suggest if the above look good.
Also suggest if any base LABEL is required at the start, there is no source for the VOB.
The development will happen over time.
If your new VOB is empty, you don't need a LABEL as a base for your release branch.
The placeholder version 0 of /main is enough.
Your (non-UCM) config spec would simply be:
element * CHECKEDOUT
element * .../release/LATEST
# (not needed yet) element * LABEL -mkbranch release
element * /main/0 -mkbranch release
element * /main/LATEST -mkbranch release
Once you have done one release, merged to /main, then it is a good idea to make a LABEL on /main, and make a new release2 branch starting from LABEL.
You can replace '*' by /new_vob/... if you want.
(If it is a dynamic view, with only new_vob mounted, it would have access only to new_vob anyway)
I have around 5000 files for which i have to create a branch(say my_branch) from main branch,checkout those files,check in and then apply label.
Its practically impossible to seperately create branch for each file and do the other steps.
There is a way to apply common label to all checkout files and check in all checked out files..that reduces my work but is there a way to create branch for 5000 files with just one cmd or are there any tool to do so
Thanks in advance
Yes, if you have a snapshot view ready to create that branch for you, meaning with a config spec like:
element * .../myBranch/LATEST
element * /main/LATEST -mkbranch myBranch
element /main/0 -mkbranch myBranch
(assuming here that your files are for now on /main)
In that case, what you do is:
copy and update your 5000 files somewhere else
clearfsimport them into your snapshot view: 5000 files will be checked out, updated, checked-in in the right branch for you, one by one, automatically.
See "How to run clearfsimport command for similar streams" as an example for the clearfsimport command.
Actually i created a view, branch and set the config secs for that view.
Its allowing to checkout the already existed files, but it does not allow to checkout the newly created files. its allow to create new elements by using "mkelem" command, but it does not allow to checkout that newly created file.
For newly created file, you should see a rule like:
element * /main/0 -mkbranch newBrach
See for illustration "Config spec rules for elements in subbranches":
element * CHECKEDOUT
element * .../bug-fix/LATEST
element * BASELINE-X -mkbranch bug-fix
element * /main/0 -mkbranch bug-fix
Rule 4 (fourth line) determines that when a new element is created, the mkbranch clause causes the new element to be checked out on the bug-fix subbranch which is created automatically with the mkbranch command.
Also, if an existing element does not have a bug-fix branch or a version with the BASELINE-X label, the bug-fix branch is created when you check out the element.
So examine your config spec, and check if that /main/0 -mkbranch is there:
cleartool catcs -tag yourViewTag
See "why I only get a clearcase version 0?" for more on that "version 0", when an element is created.
In Clearcase I have a VOB with a path like this:
\Department\ProductGroup\Product1\Development
I have a view with a Config Spec like this:
element * CHECKEDOUT
element * .../mybranch/LATEST
element * /main/LATEST -mkbranch mybranch
load \Department\ProductGroup\Product1
All the source code for Product1 is in the Development directory. Nothing I care about exists outside this directory. All references in the code are relative to this directory.
I have created the above Clearcase view in the directory c:\dev
Presently the above setup creates a directory:
c:\dev\Department\ProductGroup\Product1\Development
All the parent directories to Development are empty. I'd rather have just the following directories.
c:\dev\Product1
Where c:\dev\Product1 mapped to the VOB path \Department\ProductGroup\Product1\Development. Is this possible?
1/ Why not only load \Department\ProductGroup\Product1\Development ?
load /Department/ProductGroup/Product1/Development
Note: you can use '/', easier than '\' and Windows config spec does interpret it correctly.
1bis/ If you want to keep a general rule, you could use some "cleaning rules"
Consider this config spec
(test it in a dynamic view first, to check quickly -- that is without endless update reloading steps -- if the result does match what you need: files under Development and no files anywhere else)
element * CHECKEDOUT
# read/write selection rule for the directory and sub-directory
# where you need to work
element /Department/ProductGroup/Development/... .../mybranch/LATEST
element /Department/ProductGroup/Development/... /main/LATEST -mkbranch mybranch
# specific selection rule for the parent directories of Development
# those rules do not contain a mkbranch directive
element /Department/ProductGroup .../mybranch/LATEST
element /Department/ProductGroup /main/LATEST
element /Department .../mybranch/LATEST
element /Department /main/LATEST
# cleaning rule right there: anything outside /Department/ProductGroup/Development
# will not be selected, hence not loaded
element /Department/* -none
load \Department
That way, you always keep the same load rule load \Department, and your selection rules do the cleaning for you.
2/ Regarding your path issue, you can use Symlink but the easiest way is to use a subst
subst X: c:\dev\Department\ProductGroup\Product1\Development
And you could go on using your snapshot view within X:\
BUT that would not work because ClearCase needs:
view.dat (the hidden file indicating a directory tree is in fact a snapshot view)
a vob (which is Department in your case. ProductGroup\Product1\Development is a path within the Vob Department)
X:>ct lsview -l -full -pro -cview
cleartool: Error: Cannot get view info for current view: not a ClearCase object.
X:>ct ls
cleartool: Error: Pathname is not within a VOB: "."
For those same reasons, a hardlink with Junction on windows will not work:
c:\dev>junction Product1 Department\ProductGroup\Product1
Junction v1.05 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2007 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Created: C:\dev\Product1
Targetted at: C:\dev\Department\ProductGroup\Product1
C:\cc\xxx>ct ls
cleartool: Error: Pathname is not within a VOB: "."
So what you can do is:
subst X: c:\dev
That combined with the specific load rules from 1/ or the cleaning rules from 1bis/ will give you:
a slightly shorter path
no extra empty sub-directories
2bis/ "Devious" solution:
From the ClearCase explorer, move Development from Department\ProductGroup\Product1 to Department! That move will be recording within 'mybranch' version tree, and will not be visible for anyone else working in /main/LATEST.
Then with the subst from above, you will work within 'mybranch' in Department\Development.
X:\Department\Development
When you want to go public, make the inverse move.