I searched for a while and tried to find a way to create a branch in clearcase, but cleartool commands are used in all the articles I found.
I'm just curious that is there any other way to use GUI operation only?
Of course, you can create a branch through the GUI.
If you are using UCM:
you can open the ClearCase project explorer,
define a new stream,
create a view on it,
open the ClearCase explorer
checkout any file and select its version tree
You will see a new branch created for that file
If you are using base ClearCase
open your ClearCase Explorer
select "properties" on your view
modify the config spec of your view
element * /main/LATEST
into:
element * /main/0 -mkbranch aNewBranch
element * /main/LATEST -mkbranch aNewBranch
And when you checkout a file, you will see "aNewBranch" in its version tree.
Note: in base ClearCase, you may need to create the "branch type" first, before being able to use it in a config spec.
Again, there is a GUI for that: the type explorer. (Start > Programs > Rational ClearCase> Type Explorer)
Open it,
select the right Vob where your elements will use that branch
select "branch type",
and create your branch type "aNewBranch".
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'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.
I'd like to set-up a non-UCM clearcase (read only) view for debugging an issue reported on a old baseline which was delivered to customer.
How to view/retrieve/generate the config spec of the old baseline? so that I use this config spec to create a non-UCM clearcase view for debugging the issue.
The config spec is simple:
element * baseline_id
element * /main/0
element * /main/LATEST
(note that the /main/0 is important, especially in a multi-component vob, for the initial version of the component is registered in /main/0 when a new component is created)
What you need to find out is:
what is the baseline id? (which can differ from the baseline title).
See "Display Current Baseline with Cleartool".
You can for instance describe the stream to get the foundation baselines id:
cleartool descr -fmt "%[found_bls]CXp" stream:myStream#\myPVob
is the baseline a full or an incremental one? See "What is the difference between Full baseline and Incremental baseline in Clearcase UCM?".
If it is an incremental one, you need first to promote the baseline to a full one.
ct chbl -full -nc baseline:abaselinexxx.yyyy#\apvob
I think a much simple solution is to create a stream based on the baseline you have. That way you can even write into it without interfering nothing and even to save you changes in CC
It's very simple to create a stream based on a baseline, click the "advanced" option when creating stream as usual.
Enjoy,
Eli.
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.
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.