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.
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.
we have a branch created , config spec of which looks like this
element * CHECKEDOUT
element * .../project_name/LATEST
element * some_label -mkbranch project_name
element * /main/LATEST -mkbranch project_name
now there is a folder which looks like this
abc\bcd\efg which has certain .xls files, need to move these files to a new folder under efg
i.e abc\bcd\efg\hij\
how do I go about this?
Can someone help? Im very new to clearcase, it would be great if you can tell me any services need to be stopped or any tags need to be untagged or stuff like that
Thanks in advance :)
You can move them through the GUI, but in command line, you need to checkout the source folder and the destination folder.
See more at "To move an element within a VOB"
Check out the parent directory and the destination directory.
Enter the following command:
cleartool mv element-name destination-directory
Check in the new parent directory and the source directory.
This operation changes the location (and optionally, the name) of an element or VOB symbolic link.
For a file element that is checked out to your view, it relocates the checked-out version also. (That is, it moves the view-private file with the same name as the element.)
If the version is checked out to another view, you receive a warning message that you have view-private data that may need to be moved.
We usually use snapshot views and they work just fine.
However, I tried to use a dynamic view recently and doesn't show empty files in the working directory. We use Python so namely, it doesn't show empty __init__.py files, which breaks most of our code. All other files in the same directory, and non-empty __init__.py files exist.
Is this a known issue? What can I do?
Running cleartool ls says about the __init__py file: "no version selected".
My config spec looks something like this:
element * CHECKEDOUT
element * SubComponenet1_VersionX
element * SubComponenet2_VersionY
element * SubComponenet3_VersionZ
element /src_base /main/LATEST
Assuming the empty files are inside src_base and considering the last rule, how can a file not have a selected version?
First, try a cleartool ls in the parent directory of those file, in a shell or a DOS windows.
You can see there status, and see if they are selected by your config spec.
Check also that the config spec of your dynamic view is similar to your snapshot view:
cleartool catcs within your snapshot view
cleartool edcs from your dynamic view
For a non-UCM dynamic view to reflect an UCM snapshot view, it can be pretty complex.
It is best to create a dynamic UCM view on the same Stream.
At the very least, your config spec should end with a stop-rule:
element * /main/LATEST
# or
element /src_base/... /main/LATEST
Your last rule is only for /src_base directory, and not for the sub-elements.
My base ClearCase config spec reads like this:
element * CHECKEDOUT
element * .../Branch_F13R2/LATEST
All is good, but I am wondering what is the .../ doing at the beginning of the path? In UCM, we can see the streams and VOBS in Clear Case explorer, but in base ClearCase, how to know that if I want to check out from Branch_F13R2, I need .../ at the beginning?
That is because you don't know the parent branch.
.../ in a selection rule allows for ClearCase to select that branch, from whatever branch it comes from: /main, or any other branch.
To see more about that notation, called ellipsis wildcard, see "Find all files modified in a specific ClearCase branch?".
I would also recommend to add the rule
element * /main/LATEST
Not every parent directory has a version in the branch you are looking for, and without this last selection rule, it would have nothing to select, making any sub element inaccessible.