For a variety of terrible yet neccessary reasons, our project needs to split a UCM VOB into multiple UCM VOBs. We currently have the follow VOB/component structure:
/vobs/companyA/teamA/dev
/vobs/companyA/teamB/dev
/vobs/companyB/teamC/dev
We are restructuring into the following structure:
/vobs/teamA/dev
/vobs/teamB/dev
/vobs/teamC/dev
Is there any way to move/relocate the elements to the new components in the new VOB and retain the elements' history?
The command to do that is cleartool relocate, and its man page explicitly mentions:
Note: You cannot use relocate in a UCM component VOB or PVOB. Before you perform any relocate operation, read the relocate reference page.
So it is best to select the last meaningful baselines, and 'clearfsimport' their content (at least the right subset) in the new vobs, in order to recreate those baselines.
Related
I have used below command but it provides all foundation baselines.
cleartool descr -fmt "%[found_bls]CXp" stream:myStream#\myPVob
Is there any way to get foundation baseline of a single component?
I mentioned before how to get the foundation baselines for a stream.
But fmt_ccase does not include foundation baselines for a component.
The only two directives appplied to an UCM component are:
%[initial_bl]Xp: Initial baseline of the component
%[root_dir]p: The root directory for the component
So you have two options:
%[component]Xp (for an UCM baseline), for describing each baseline you get from %[found_bls]CX, getting each component name that way.
Once you get the expected component name, you know its baseline
%[components]CXp (for an UCM stream), listing the components for which the stream has foundation baselines.
If the second option (%[components]CXp), applied to a stream, lists the component in the same order than it list baselines with %[found_bls]CXp (for a stream), then it would be quicker (the baseline for the third component would be the third baseline listed by %[found_bls]CXp)
But if the order is not the same, then you must loop on each baseline from %[found_bls]CXp, and describe each of them with %[component]Xp, until you get the component you are after.
Components don't have "foundation" baselines. The concept of a "foundation" baseline only applies to streams. So, you will need to check this on a per-stream basis.
Complicating this further is the concept of "composite baselines" which are themselves a collection of baselines (and these can be nested).
Off the top of my head, you would start by looking at either the foundation or recommended baselines of integration streams, and breaking that down by component (including by drilling down into composite baselines). Unless the integration streams are very new, the "recommended" baseline may be more useful than the foundations.
I want to add components to a stream (development and integration) in clearcase. How do I add the components using commands (cleartool) ?
A simple cleartool rebase should be enough: by rebasing a component baseline, that would add the component automatically to the stream.
Execute that in a dynamic view (faster than a snapshot view)
The related commands are:
cleartool chstream, that you can use to:
recommend baselines.
remove a component (but that is not your case)
And cleartool chproject, used to to convert non modifiable baseline to modifiable.
To add multiple baselines, assuming you don't have a composite baseline through a rootless component (which could group all those baselines under one), you would have to loop over your different baselines, ad rebase them one by one on your stream.
Note that with one command, you can list all existing foundation baselines of a stream, as I did here:
cleartool lsstream -fmt %[found_bls]p -cview
That means you can then double-check which baselines are already present (and would not need to be rebased again), and which baselines would have to be rebased.
I have this issue while rebasing the stream:
cleartool: Error: Can't switch to baseline because the stream has made changes
based on the current baseline.
giraffe_pvob is a non modifiable component on
tiger_011 project and there were no changes done on this component
by the stream.
I would like to install the preop trigger to prevent any new baseline on this stream. so how should I proceed? Will this prevent any rebasing issue like above?
Thanks !!
You cannot prevent the creation of the baseline, but you can prevent the situation which leads to said baseline on a non-modifiable component.
This is called a parasite baseline, and is one of UCM flaws.
It is caused by a dependency, as explained in "ClearCase UCM - best practices using components".
A1
B1
B2
Putting a baseline on A will create a parasite baseline on B, even if B is a non-modifiable component...
(more details in this thread)
The only preop I usually put is one (on rebase) making sure none of the foundation components (like B) of a stream are part of the dependencies of another (modifiable) component (like A depending on B)
Is it possible to open a view (snapshot or dynamic, maybe readonly) on any given baseline (recommended or older) in a stream (integration, development or child) for performing some tasks and then remove the view when done? How?
To open a view to a given baseline, you actually need a view associated to a stream with said baseline as a foundation baseline.
That means you need to rebase that stream first, which is:
not always desirable (since you would need to merge said baseline with current content, and that doesn't always make sense)
not always possible (you can only rebase a sub-stream with baselines coming from its immediate parent).
What is possible is to:
get the stream on which your baseline has been put
make a sub-stream from that stream, taking said baseline as the foundatio one
create a snapshot or dynamic view on it
do your work
put a new baseline, and deliver it to its parent stream
obsolete that sub-stream (and you can delete your view if you want)
Note: you could create a base ClearCase dynamic view (ie non-UCM) with a config spec you could then change as you want, but that wouldn't allow you to checkout and modify any file.
That would only be a convenient way to visualize any baseline of your choice.
I've previously documented my opinions on Clearcase as a source control system, but unfortunately I am still using it. So I turn to you guys to help me alleviate one of my frustrations.
We have just moved from a one-branch-per-developer system, to a one-branch-per-task in an attempt to improve some of the issues that we've been having with determining why certain files were changed. Generally I am happy with the solution, but there is one major issue. We are using simple scripts to start and end tasks which create a new branch named with the username and task number and then updates the local snapshot view to have a config spec similar to the following:
element * CHECKEDOUT
element * .../martin_2322/LATEST
element * /main/LATEST -mkbranch martin_2322
load /Project/Application
Let's say that my project has two coupled files A.cs and B.cs. For my first task I make changes to A on the branch. Then I need to stop working on task 2322 for whatever reason and start work on task 2345 (task 2322 is not finished, so I don't merge it back into main).
I create a new task branch 2345, edit both A.cs and B.cs and merge the results back into main. Now I go back to work on 2322, so I change my config spec back to one defined above. At this point I see the A.cs file from the task branch (as I edited it earlier, so I get the version local to that branch) and the latest version of B.cs from main. Since I don't have the changes made to A.cs on the 2345 branch the build breaks. What I need instead is to be able to pick up task 2322 from where I left off and see it with the old version of A.cs - the one that was latest in main when the branch was created.
The way I see it I have a few options to fix this:
Change the config spec so that it gets files from main at the right date. This is easy enough to do if I know the date and don't mind setting it by hand, but I can't figure out how to automate this into our task switching scripts. Is there anyway to get the creation date of a branch?
Create a label for each branch on main. Theoretically simple to do, but the labelling system in our install of CC is already collapsing under the weight of a few hundred labels, so I don't know if it will cope with one per developer per branch (notice that the task in my example is 2322 and we're only about an quarter of the way through the project)
Merge out from main into the task branch. Once again should work, but then long running branches won't just contain the files changed for that task, but all files that needed to be merged across to get unrelated things working. This makes them as complicated as the branch-per-developer approach. I want to see which files were changed to complete a specific task.
I hope I'm just missing something here and there is a way of setting my config spec so that it retrieves the expected files from main without clunky workarounds. So, how are you guys branching in Clearcase?
A few comments:
a branch per task is the right granularity for modifying a set of file within a "unit of work". Provided the "task" is not too narrow, otherwise you end up with a gazillon of branches (and their associated merges)
when you create a config spec for a branch, you apparently forget the line for new elements (the one you "add to source control")
Plus you may consider branching for a fix starting point, which would solve the "old version of A.cs - the one that was latest in main when the branch was created" bit.
I know you have too much labels already, but you could have a script to "close" a task which would (amongst other things) delete that starting label, avoiding label cluttering.
Here the config spec I would use:
element * CHECKEDOUT
element * .../martin_2322/LATEST
element * STARTING_LABEL_2322 -mkbranch martin_2322
# selection rule for new "added to source control" file
element * /main/0 -mkbranch martin_2322
load /Project/Application
I would find this much more easier than computing the date of a branch.
do not forget you can merge back your task to main, and merge some your files from your finished task branch to the your new current task branch as well, if you need to retrofit some your fixes back to that current task as well.
You can get the creation date for a branch by using the describe command in cleartool.
cleartool describe -fmt "%d" -type martin_2322
This will printout the date and time that the branch was created. You can use this to implement your first option. For more information, you could read the following cleartool man pages, but hopefully the above command is all you need.
cleartool man describe
cleartool man fmt_ccase
We use Clearcase, and we find that creating a branch for a release is often much easier than doing it by task. If you do create it by task, then I'd have a 'main branch' for that release, and branch the tasks off that branch, and then merge them back in when finished to merge them back to the trunk.