Can a ClearCase administrator or a project manager delete a project including all its streams, views, baselines, activities etc.? How?
You cannot easily delete a project, unless all its streams are deleted
You cannot easily delete a stream if there are versions created on a branch made from that streams (or if there are any views or any activities attached to that stream).
You cannot easily activities unless you have deleted first every versions in it (or move them to another activity)
and so on...
Bottom line, ask for the owner of the project to obsolete it (and its streams):
cleartool lock -obs stream:astream#\myPVob
cleartool lock -obs project:myProject#\myPVob
It is a much more lightweight operation with less side-effects and:
the project and its streams will be invisible
nobody will be able to checkout/checkin any file on those streams (ie on the branches created from those streams)
Related
I am encountering a problem with Clearcase. I do apologise in advance if I am unclear, or redundant since I am quite new to this VCS, coming from a Git background mainly, I might not know how to search correctly regarding my problems.
We have a new version (non-relevant to CC, business-wise) of the application every few months, and we create a new VOB and stream for each version each time. We have a generic stream in which we deliver the last baselines from a finished version, add a new baseline, then export the contents of the generic stream to a new VOB and Stream.
My problem is, being hasty I actually delivered into the the generic stream, not the last baseline, but a previous one. And on top of that, I added a brand new baseline to the generic stream.
I need to be able to deliver into my generic stream, the very last baseline from our previous business version of the application.
(I am mostly manipulating Clearcase project explorer, since I don't really know the cleartool command. I tried to use a few CLI solutions but could not manage to do so, but might be linked to how our Clearcase server is)
In order to do that, I tried to :
Delete the delivery activity. But there is an error when I try to do that : "Error : Cannot remove an activity with versions in its changeset". I tried to bypass this, helping myself with google, but could not manage to do so. I am afraid this is normal Clearcase behaviour, and cannot pursue this way.
Redeliver our last business version correctly, but it did not work because of my newly hastily created baseline in the generic stream.
I would take up on any clue, indication lead, since I cannot manage to find how to correctly advance upon this matter.
Thank you in advance.
It is simpler to:
deliver to the generic stream the right content (on top of the wrong one) and set a new baseline
rename the previous baseline into a "DO-NOT-USE" name
cleartool lock -obsolete the baseline, to make it invisible (rather than trying to delete it)
That way, you can resume your successive delivers/imports of each release, and forget about the wrong one.
If the baseline you created in that stream is the most recent baseline, and has not yet been used by another stream (either pulled in a rebase or delivered to another stream), you should be able to just remove it.
In any event, since your plan is to move forward by delivering a more recent baseline created in the same parent stream to this "generic" stream, you can just deliver the right baseline to this stream, make a new baseline, and optionally lock the previous baseline.
A couple of UCM gotchas you may want to be aware of:
If you deliver a baseline to another stream, the source baseline is permanently irremovable.
ALL deliver operations deliver baselines. If you don't create a baseline, the deliver operation creates a "deliverbl" baseline to deliver.
Removing streams is either non-trivial or impossible.
Removing projects where development work has been done is usually impossible.
For future reference, to remove an activity that is NOT in a baseline:
Describe the activity on the command line to get the list of versions. You may want to redirect the output into a file so you can copy and paste the version info into the next step more easily. To describe the activity, you need to use "cleartool describe activity:{id}#{project VOB tag}"
Remove all the versions in the change set using "cleartool rmver -xhlink {version ID}"
Remove the activity. Since the delivery is apparently completed, the activity should not be set.
Is there a ClearCase equivalent to hg shelve (or git stash for those of the other persuasion)? The closest I can think of is doing uncheckouts and saving keep files, but that means I'd have to hunt down the keep files afterwards, re-checkout the files and merge. I realize that ClearCase and Mercurial/Git have different philosophies behind them, but I'd be interested if there is any work in making ClearCase more "usable".
I listed a few for other version control tools, but none for ClearCase.
I explained, for ClearCase UCM, that a shelve command isn't easy to implement.
Instead of just saving the .keep files, you could save patches (unix diff between a .keep and its original version), since a patch can be re-applied later.
The other approach is to modify the config spec (easier when in a non-UCM view) in order to checking the currently modified versions in a new branch (see this config spec)
You can then decide to merge that branch later.
The philosophy is quite different.
In Clearcase, if you need to work on another branch/release, you usually have to use another Clearcase view. If you have Clearcase/UCM, it is even more true as you would use another view attached to another UCM stream. You would not be able to use the same view, whereas in Git, you would be able to stick to the same clone and perform a git stash, git checkout in order to start working on another release.
Now let's assume you need to work on another feature, for the same release. Under Clearcase/UCM, you would be able to create a new activity (cleartool mkact) and work on this new activity, using the same view. All the changes made will then be associated with this new activity. You will also be able to switch back to the previous activity using the command cleartool setact. The tricky part is if you need to deliver the activities separately. This will not necessarily possible as you might need to deliver both at the same time depending on the content of the changeset. This doc about determining dependent UCM activities is quite useful. If you need to move some changeset between activities, you can use the command cleartool chactivity with -fcset and -tcset options.
As a summary, with Clearcase UCM, if it is for different release, switch views and streams. If it is for the same release, play around with the UCM activities, knowing that it is less flexible than git stash.
I'm exploring an old ClearCase (UCM) repository (trying to migrate to git, but that's rather not important here). I found a case (or rather many cases) of a file, for which I cannot see history past some point. When I use cleartool lshist (or browse versions in a Rational GUI tool for CC), the history of the file appears to start (as version 0 or 1) in a separate development stream, and then later gets delivered into main stream (again as version 0 or 1 in this stream). But from independent sources, as well as from "baseline release streams", I know that a file was present in this path since much, much earlier (some year or two earlier).
What could be the reason why this happens?
How can I see the full history of the file, starting from the point in time when it was really first created (or some "other" file in the same exact path)?
It can depends on how the events have been scrubbed from the vob: see "About ClearCase event records in the VOB database".
I know I lost some events when raising the VOB family level during ClearCase upgrades.
It can also depends on how the branches and UCM streams have been managed: they could have been obsoleted, or in some case even deleted.
In case of "obsolete", check the filter of a cleartool lsvtree -graph window: you can ask to see all versions, including ones associated to obsolete streams.
We use ClearCase as control version system.
In our system sometimes we make releases without some developers commits because of time limit.
For example I made some changes in six classes but another user did changes in all or some of them also. And I have to commit code without his changes. So I scan my files with previous versions so that I can revert his changes. But it's a slow and boring process.
Is there another way to do that? Maybe an extension or a script?
The only way to automate that process is through:
subtractive merge or negative merge (as described in this IBM article):
cleartool merge -to filename -delete -ver \main\branch\version_number
cset.pl, which can take all the checkins of an UCM activity and cancel them.
See "Clearcase: how to rollback all changes on specific branch?".
But this is for UCM (which might not be your case)
In both cases, the idea is to create a new version which cancels the version of your other developer.
While at home for personal projects i use Mercurial, at work we're using ClearCase.
I am attempting to run a few horizontal (touching lots of source files) refactorings in Visual Studio for the code base, however, for since each file is locked by ClearCase, it has to be unlocked and prompts for the actual activity that the check out is for.
In Mercurial, there's no such concept as far as i'm aware of: files are not being locked at all at any point of time!
Is there a way of doing such a refactoring, or any other operation that acts on multiple files, without having to check out each and every one manually?
In a DVCS (distributed VCS like Git or Mercurial), you simply cannot "lock" a file, since all the other repos wouldn't be aware of such a "status".
But with ClearCase and its locking mechanism (optimist with "unreserved checkout" or pessimist with "reserved checkout"), you need to make a checkout to tell ClearCase you will modify some files.
However, you could also, for large refactoring:
make and update a snapshot view
set all the files as writable (through an OS-based command, not through ClearCase "checkout")
perform your changes
search for all hijacked files and checkout/checkin those files then