Is there anyone who knows a way to find all added files in a CCE view? just to verify that no file is missing before applying label.
thank you.
No file missing means some files might be still in checkout mode, but even then, applying a label would be applied on that checkout version (you would need to make sure and checkin them later)
You can list files still in checkout here.
A better query would be to list all files with versions more recent than the previous label (assuming base ClearCase here, not UCM)
You can use the date for instance to list all files with version newer than a date
ct find -all -type f -version "{created_since(11-apr-2013) && brtype(branch_name)}" -print
That way, you will know all added files, and can check if there are any missing before applying a label.
The OP Frimus proposes an alternative solution in the comments:
I resolved the issue by creating an other view with the same config spec,
and I compare the two views.
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 need to get a list of user names for every version listed in the version tree of an element, and then repeat for every element in the directory.
So far, I have come up with the following:
> cd M:\path\to\folder
> cleartool find . -version "created_since(01-January-1979.00:00:00)" -exec "cleartool describe -fmt ""%Lu\t%Fu\t%n\n"" %CLEARCASE_XPN%"
I chose a really old date thinking our VOB is younger than that date.
This gives me the same information for every version of an element because it's looking at the element owner, not the individual that contributed a specific version.
I'm using the following pages for reference:
http://www.ipnom.com/ClearCase-Commands/describe.html
http://www.ipnom.com/ClearCase-Commands/fmt_ccase.html
http://www.ipnom.com/ClearCase-Commands/find.html
http://www.ipnom.com/ClearCase-Commands/query_language.html
This might be a simple case of RTFM. Any help is appreciated.
You need to check if %n (used in the -fmt_case directive) returns the element name of the version name:
if it is the element name (without any extended path information, as in ##/main/.../x), then it would be normal for the cleartool describe to return always the same information.
if it is the extended path, as I would expect with %CLEARCASE_XPN%, then %u should be the user associated with the event (the version), and not the "element owner)
%u
Login name of the user associated with the event.
Small note, I always prefer using double-quotes around %CLEARCASE_XPN%, in case the path filename has a space in it.
-exec "cleartool describe -fmt ""%Lu\t%Fu\t%n\n"" \"%CLEARCASE_XPN%\""
Upon closer inspection, it looks like the command I posted above is sufficient. I saw a bunch of user names that were the same and thought they were all the same, but that's not true. I'm seeing different user names for different versions of the same element as I originally wanted.
If you work on a multisited VOB, do not forget that the owner of an object created on another site will be the VOB owner on your site. Therefore, if an object was created and modified only in a remote site, all of its tree and version would be owned by the VOB owner.
Of course, I assume you are in non preserving mode for identities for your replica synchronization (see the Changing preservation mode for mode infos). In most cases, you would not want replication to preserve identities, because each site has its own set of users.
I have a static view with some files checked out that I am working on. Someone else checks in a bunch of changes that I want to add to my view. So, I run update on my view. It turns out they changed a file I have checked out. Now my view is left only partially updated and may not even compile until I figure out which checked out file I have to manually merge.
I know I can reserve my checkouts, but that blocks other devs from checking in stuff they are done with.
According to: http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_update.htm
update does not apply to files or directories that are checked out to the current view.
So, it seems it's working as the atria/rational/IBM folk want it to work. I don't understand why it works this way.
Is there any way to update my static view and also automatically merge changes into my checked out files?
Is there any way to update my static view and also automatically merge changes into my checked out files?
Not really, since a checked out file is a file being modified locally, and cleartool update tries very hard to not touch any local file.
Your checked out file is selected by the element * CHECKEDOUT selection rule, which means any update won't update it (it is already selecting the right version).
You need to check in those file (triggering the merge, similar to "To merge the latest version to a hijacked file"), and check them out again.
But that isn't always possible since it would make a work in progress visible (checked in) to other views in the same branch.
The only other solution is to compute a patch between the checked in version and your checked out file, and apply that patch cleartool lsco -all -s -cview | xargs cleartool diff -diff, with the difficulty to diff between your checked out version and the LATEST version.
we have created a component in UCM. Many files were changed since but few files were not at all changed after version 1.
We can find the list of files using createdsince. but in this case we need to specify the date. Is there any way to find the list of files which are modified since creation.
In other words find list of files which has version greater than 1 in version tree.
You need to compare current versions with the stream/1 versions, and that isn't always the initial baseline of a component.
Actually, if you didn't imported an initial non-UCM label as a baseline, then the initial baseline is empty (no version in it).
The trick is, when using the query language, you cannot use version selector and a query
So, what you can do is apply a label to all version 1, and then look for all elements which have at least one version without that label (see find examples).
cleartool find . –version 'version(.../streamName/1)' –exec "cleartool mklabel V1 \"%CLEARCASE_XPN%\""
cleartool find . -version '{!lbtype(REL1)}'
Good morning,
is there any way to exclude only one particular directory from a snapshot's load statement, e.g. I want to load a whole vob named 'PM_CT' except the \PM_CT\lost+found directory
... is there an elegant way to do it? And how would I generally exclude all lost+found directories across multiple loaded vobs?
Cheers and Thanks,
-Jörg
I would like to make an addition to the previously posted answer:
The lost+found directories
To exclude the lost+found directories across all VOBs you can modify the previously proposed selection rule to be more generic:
#Skip the lost+found directories
element .../lost+found -none
However, using the '-none' flag causes the Windows ClearCase client to list errors when updating a snapshot view:
Unable to load "lost+found": no version selected in configuration specification.
Unable to load "lost+found".
It also does not properly unload any previously loaded folders or files, so you may need to recreate your snapshot view (or unload/reload the VOB) with the new selection rule if you really want to clean out the lost+found directories...
Elegance
For excluding any normal folder, the "elegant way" would be to specifically load the /main/0 version of the folder:
#Exclude the contents of a directory
element /VOB_name/folder_path /main/0
This will cause the folder to be loaded as empty and will not produce an error. It will also properly unload any loaded files. It unfortunately does not work for the lost+found directory, because it is always listed as version /main/0.
element /PM_CT/lost+found -none
The "elegant" way consists of:
adding a selection rule (here "-none")
loading all PM_CT without aking any question (load /PM_CT), if your view is a snapshot one
Note: in a config spec, always use "/": it is easier, and Windows as well as Unix ClearCase views will be able to interpret it.
Caveats:
the previous solution is for one vob, I do not think you could use "wildcard" for multiple vobs
the '-none' option can cause a snapshot view to fail during a deliver or rebase (UCM merge): for that kind of operation, a dynamic view would be more suited. That is for CC 2003.06 and early 7.0. I think it works better with the latest CC7.1.0.2
Note: that selection rule can also be used for dynamic views, in order to mask some directory you would not want to see.