I have a file in lost+found which is checkedout but I do not see any viewreference. How can i remove the file?
I'm Checking in windows system. When I do a version tree, I see a view that was created in some unix system. I'm not able to get the uuid of the same.
How can I delete such file?
For the checked out state, You should be able to get the view uuid in the same way as in the previous question "How do I delete check-outs from a particular view in clearcase?".
That lost+found folder is part of a vob and a cleartool describe -b vob:\Avob should list the uuid of the unix view.
But if you are not sure which uuid matches the actual name of the old view you see in the version tree, you can check for that name directly in the registry server.
There are different option:
cleartool rgy_check -views
But also, since I have access to the registry server, I can do a simple grep of the name in the var/rgy folder where view_tag is:
<user>#<server> /path/to/ClearCase/var/rgy
$ grep -i <view_name> view_*
view_object:-entry=view_object;-hostname=server;-local_path=path/to/<view_name>.vws;-owner=<name>;-view_uuid=e670fe8a.fb0540e5.83f4.7f:82:a6:s8:e1:1a;-attributes=sumview;
view_tag:-entry=view_tag;-tag=<view_name>;-title=<title_View>;-hostname=server;-global_path=\\server\views\path\to\<view_name>.vws;-region=<region>;-view_uuid=e670fe8a.fb0540e5.83f4.7f:82:a6:s8:e1:1a;
That way, from then name, you get back the uuid and can remove the checked out state from the vob.
Regarding the file itself (in lost+found), see technote "About the lost+found directory", that I mentioned in "How do I retrieve a file if I undid a folder checkout in ClearCase?".
There are two possible ways to remove an object from the root of the lost+found:
The object can be moved to a new location in the VOB using the cleartool mv command
The object can be permanently deleted from the VOB.
Be careful with the second option (which involves rmelem), especially in UCM (where that object could have in previous versions baseline labels attached to them)
Related
I'm new to CC and I'm coming from Git and Mercurial background, probably thats why ClearCase confused me so much. I've been assigned a task to migrate latest CC's revisions to Git. Problem is that I couldn't manage to checkout any branch other than main in CC.
I have a view that displays all VOB's /main/LATEST revision. I assume, main branch's latest revision.
element * CHECKEDOUT
element * /main/LATEST
Now I need to get the list of other branches in a particular VOB. To do that, I navigate from terminal in that folder and run
cleartool lstype -kind brtype -invob /%VOB_NAME%
and I can see the list of branches. Correct me if I'm wrong, but I assume, it displays only the branches relevant to VOB(%VOB_NAME%).
Now I need to checkout the branches. What is the standard way of doing this. I tried updating config spec with something like:
element * /%VOB_NAME%/%BRANCH_NAME%/LATEST but it doesn't seem to work.
Pretty sure I'm not doing it correctly.
Also for migration purpose, I'll need to automate the steps to acquire branches and checkout the branches. I guess updating config spec to switch branch in a view takes some time and probably is an async operation, so is there a way to determine when view finishes updating?
Or maybe there's command line option to switch branch for a particular VOB in a view?
So in short, here's my questions I'm struggling with:
Than
Am I acquiring VOB branches correctly?
How can I checkout a particular branch?
Is there a way to determine when checkout finishes?
thanks
UPDATE
ok I tried #VonC's recommendation so my config spec looks like this:
element * CHECKEDOUT
element * .../heine_1/LATEST
element * /main/LATEST
If I'm guessing correctly, one VOB containing branch named heine_1 should checkout that particular branch, the rest of VOBs will stay on main branch, but this is not the case. When I run cleartool ls inside that VOB, its still on main branch. All folders are postfixed with Rule: /main/LATEST. So I guess it didn't switch the branch.
Thanks
There are a few questions in the original question and the comments.
Addressing the configspec issue first...
The syntax of an element rule is:
element {path} {version rule} {optional clauses}
If you need a VOB-specific rule, you can do something like this:
element \myvob\... ...\myvobbranch\LATEST
element \myvob\... \main\LATEST -mkbranch myvobbranch
The "..." in the path means "this location and everything underneath it."
The "..." in the "version rule" means that the branch name is at the end, so this would match /main/myvobbranch/LATEST, /main/br1/myvobbranch/LATEST, etc.
If you're working on a branch, you generally want new files or work to appear on the branch you are working in, and the second line makes that happen.
Everything in a configspec is case sensitive, so be aware that "LATEST" is not "latest."
Since the view was created for you, I'm reasonably certain that it is a dynamic view. If it is mapped to a drive, it's definitely dynamic. If you need to know for sure, you can CD into the "working area" of your view and run "cleartool lsview -pro -full -cview" and look at the "attributes" line. The line for a dynamic view will look like this:
Properties: dynamic readwrite shareable_dos
On the direct questions:
Yes, you are acquiring the branch list correctly.
By default the checkout is done using the version selected by the view, you can use cleartool checkout -branch {full branch path} {file name} to check out the latest on a branch, or cleartool checkout -version {version id} {file name} to check out a version other than the latest on a branch. I would not recommend either as a normal practice. The -branch will cause checkins to go to the element's parent branch. The -version would require add a requirement to perform a merge to get the checkin to complete, which would also go to the version's parent branch.
Checkout is finished when the command finishes.
A big "new user gotcha" is that directories are also versioned objects. If you're adding files to source control, you need to remember to check the directory in so that they are visible by others with similarly configured views. The ClearCase GUIs have this behavior as a default if you started the process with the directory NOT checked out, but not if you explicitly checked out the directory beforehand.
I have a dA/fC##/main/0 that was created from a new file added to dA##/main/branchA/3. The new file on branchA became dA/fC##/main/branchA/1
Successive changes on dA/fC##/main/branchA/1 eventually end up on last version of dA/fC##/main/branchA/17.
Then dA/fC##/main/branchA/17 were merge from branchA into main creating dA/fC##/main/1.
However dA/fC##/main/1 does not belong to any version of dA##main/*.
I want to add dA/fC##/main/1 to dA##/main/40 so dA##/main/41 will contain dA/fC##/main/1.
What are the ClearCase console commands to run on linux?
Make sure the destination view selects /main/LATEST, and the version created will be the one expected.
Main advice: use a different view for the merge, one which is configure to
element * /main/LATEST
Or create a new one, preferably a dynamic one.
For a single file, once merged, you need to merge its parent folder too (or you won't find a version of that folder listing that file at the right version)
On the destination view, display the version tree of that parent folder, right-click on the version where fC was recorded (dA##/main/branchA/4), select merge to, and click on version 40.
See also "How files and directories are merged".
Each version of a Rational ClearCase directory element contains the names of certain file elements, directory elements, and VOB symbolic links.
Now, if you are sure merging branchA was about fC only, you could have done the merge of the file and its parent folder in one command: cleartool findmerge.
See "ClearCase: findmerge usage"
cd /path/to/view/avob/dA
cleartool findmerge . -nc -fver .../branchA/LATEST -merge
That would have merged fC and dA.
I used the merge GUI to merge the version of dA##/main/branchA/4 where dA/fC was first added into dA##/main/40 check-out.
This added dA/fC to the main view that is configured to get element * main/LATEST
I see now dA/fC##/main/1 on main and can commit.
How to copy an element or file from Clearcase with a particular label, without applying that label in config specs.
I don't want to change the config spec of my view, but I need to access an older version of one of my selected files, and I would like to do so directly from my existing view (again, without changing anything).
I know the version I want to restore (from instance version 2, even though I am selecting currently version 3 in my view).
What cleartool command would you use in order to access said old version?
You can use the extended pathname, but only using a dynamic view (any existing dynamic view, not particular config spec required).
The article "To open a version not currently in your view from a command prompt using a version-extended path" mentions that you can use a snapshot view too, but you would need for:
the element to be already loaded (obviously not at the version you want)
the old version to be copied into the view (as a private file): cleartool get -to prog.old.c prog.c##/main/r1_fix/1
Note that the contextual menu of a version tree includes a "Send To" entry which would effectively do the cleartool get (i.e. the copy) for you.
But in a dynamic view, you don't need to copy anything, you can directly reference any old version:
cp foo.c##/RLS4.3
cp include.h##/main/bugfix/REL2
See also version selector:
If a version label was defined to be one-per-element, an additional link/file system object appears at the top level of an element's directory tree.
For example, if BL3 is a one-per-element label, these version-extended pathnames are both unambiguous references to the same version:
hello.c##/BL3
hello.c##/main/bugfix/patch2/BL3
In effect, this feature allows you to reference a version without knowing its exact location in the version tree.
In a dynamic view, when you see hello.c in your view (and that can be any selected version, not the one you want with the label), you actually can do:
cd hello.c##
dir
That will list all the unique labels for you to choose from.
I'm doing some scripting with ClearCase and I have to provide a pvob name.
I'm in a context of a view (dynamic or snapshot) and I have an element name (e.g. <path>\filename.cpp) or specific element and file version (<path>\filename.cpp##\main\versioname\2)
How do I get its pvob?
Seems like I have to figure out the vob name and then find its linkage to a pvob?
Thank you
There is no direct link between a vob element and a PVob (which contains reference to UCM objects)
What you can do is, within the current path of your element:
cleartool lsstream -cview
That will give you the name of the Stream of the view, which is attached to a PVob.
However, your element could be part of a component from another pvob.
Another option is to list all the components for all pvobs, with their root directory, and check the one with a root directory similar to the path of your element.
Note: one other link is in the activity: a cleartool descr -l yourElement would display the activity (and its pvob).
But again, that pvob can be different of the component one from which your element is part of.
A bit more direct link: do a dump of your element
cleartool dump -l /path/to/your/element
[...]
derived objects:
hyperlinks to object:
arrow=1249731306
type=27209
hlink vob=90b77fed.efb24bb6.8312.8e:09:7f:84:65:a1
hlink obj=64856a02.8d9d4624.abae.09:94:b0:e7:9c:2e
from vob=90b77fed.efb24bb6.8312.8e:09:7f:84:65:a1 <=====
from obj=20b6c0e8.270e4354.91f5.02:5c:6f:ed:41:54
to vob=60efb222.0e034a34.aa4b.80:65:c3:9c:d4:ca <=====
to obj=eb7ec24a.510e4e03.8403.0b:e8:dd:3d:5c:db
Your element is linked to two vobs:
The actual Vob (which contains files)
The PVob (which is an 'ucmvob', ie a pvob)
You can list all your vobs, asking for their oid:
ct descr -fmt "%On %[plevels]p" vob:\avob
You can check if its oid matches one of the hyperlinks of your element.
Note: I use %[plevels]p because it is only valid on a pvob!
Is it possible in clearcase to checkout a file for modification such that it is impossible to check it back in? I’m going to be hacking some files on a private branch, only some of which I want to ever check in. I want to eliminate the possibility of accidentally checking in unwanted changes. (I know we can write a trigger to check for magic keywords in the checkout comment; I'm look for something built-in to CC.)
"Hacking some files" is spelled in ClearCase lingo: hijacked files in a snapshot view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a snapshot view
change the read/write right (at the OS level, nothing to do with ClearCase here)
modify them directly (without checkout them first, hence the "hijacked" state)
The OP Kevin Little adds in the comment:
Alas, we only use dynamic views
Easy enough:
"Hacking some files" is also spelled in ClearCase lingo: eclipsed files in a dynamic view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a dynamic view
copy the files you need to modify as aFile.tmp
modify the config spec to not select them
copy them back to their original name (they became "eclipsed" as their private version override their official versioned counterpart)
remove the "none" selection rules from the config spec
modify them directly
To not select them, add to the config spec (ct edcs) before the other rules:
element /a/path/to/aFile1 -none
element /a/path/to/aFile2 -none
...
To restore them, all you have to do is move or remove those files.
They will be dynamically be replaced by their original and still versioned element.
I don't know about the administration. From a user standpoint, you could have 2 views. In one view, checkout the files you don't want to check in. In the other view (your view), check them out unreserved. Then, if you try to check them in, you'll get an error because they're checked out to the other view.