We selected vob names aligned with our project name ( do not confuse project name with UCM project name) so that we can easily distinguish.
But recently our project name has been changed as we merge 2 products into one.
Some people suggested to rename the vob to indicate the project name.
We tried to analyze the impacts from development and build & release perspective.
There were very little changes, here and there we had to change the path variable to indicate the latest vob name.
So we agree for renaming the vob name.
Then as Clearcase admin i had to do impact analysis.
When i asked advice from senior Clearcase admin. They listed possible impacts such as below.
symlinks across vob will be broken so they may need to repair.
It is better to clear all check out items before changing the vob name
vob will be locked to prevent users from using the old vob name while name change.
Vobs has to be unmounted and remounted
Snapshot and CCRC views may be affected , so it has to be resynchronized.
and etc.
Has any one tried vob rename in your project? Can you share the practical impacts which you have faced which will be helpful for us?
If you already tried and decided not to do it again by any means , can you advice why it is not practically advisable to do so?
Thanks in advance.
Most importantly, your UCM components won't work anymore: you cannot change their root directory (ie path within the vob, or vob itself), even though you can change their name (their "title").
And that is independent from UCM project name (the UCM project don't care about UCM rename, only the UCM Streams do)
Frankly, when face with this kind of refactoring, I:
keep everything in place, but locked and in read-only
start fresh with a new component/vob, importing the latest baseline.
Related
We have a current set up of VOB such that source code and documents reside in the same VOB.
To reduce the VOB download time we now want to move the documents to a new VOB, so that only the code part remain in the old VOB.
Since there are lot of folders and files, its not possible to manually relocate each file/folder.
To do this, we need to write a script which will detect file types by their extension and move file types such as .doc,.pdf, .txt to the new VOB.
VOB server is Windows Windows 2008 R2 Enterprise edition.
I'm a novice!
Can someone help me out with the script?
Thanks
Nush
The process would involve cleartool relocate: see "Relocating elements to another VOB".
The best practice is to:
group all the right elements you want to relocate in one folder (cleartool move)
remocate that folder
It is best if what you want to split is cleanly group is one folder structure.
Note that relocate wouldn't work if you are using ClearCase UCM though.
See this article:
The reason for this restriction is immutable baselines: if an element has ever been in a baseline, it can never be moved to another place; the baseline needs to know where to look for it. So a UCM element really can't be relocated.
What I understand is that,
PVOB is a special type of VOB that is used when UCM is
implemented as the software configuration management process.
But my doubt is how is it different from VOB? I am new to CC but, as far as I know, even PVOB contains the same information as VOB.
Can anyone explain me?
PVob is like a vob in that it can version files and folders.
But by convention, you don't use a pvob to "add to source control".
You use a PVob as a "admin vob" for a classic Vob in order to declare component(s) in it, and to manage all the matadata associated to UCM:
Projects
Streams
Activity
Merge Hyperlinks for deliver and rebase
In that case, as I mentioned here, PVob are visible in the ClearCase project Explorer, not the ClearCase Explorer.
As any "AdminVob", a pvob manages datatypes for the associated vobs: see "VOB datatypes and administrative VOB hierarchies".
Simply, a pvob will manage UCM types as well, making projects, streams and activities visibles for all the associated UCM vobs (which contain the actual data).
You can actually group pvob in a hierarchy, as explained in "Multiple PVOBs and a common administrative VOB".
If projects in one PVOB need to modify components in other PVOBs, your Rational® ClearCase® administrator needs to identify one PVOB to serve as a common administrative VOB for the PVOBs and the component VOBs.
In Figure 1, PVOB1 and PVOB2 use PVOB3 as their administrative VOB.
At our work, we are forced to use Clearcase UCM as our central repository (specifically for labelling/baselining, builds and code reviews), but our team wants to use Git as our real SCM system.
What we want to achieve is essentially a scraping service that takes the commits as they are pushed to our central Git repo, and push them on to a Clearcase VOB that is read-only as far as the development team is concerned, including important information such as the comment and the user name (exact date/time matching is not important, but getting the user correct is).
Our centralized Git server has been configured (using the excellent scm-manager) to accept Windows domain users and passwords, and our Clearcase servers use Windows domain accounts, but I am unsure how a scraper service would "impersonate" the correct user so this information is duplicated correctly in Clearcase.
I thought the chevent command might hold some promise, but that only gives access to the comment.
Is there any way to amend the details of a Clearcase event record once it is in the database, in particular the user-name? Or is there a better way to do this?
Again, we don't need a bi-directional bridge - all access to the Clearcase VOB as far as code commits is concerned would be through the scraper.
ClearCase is a file-by-file SCM, not a revision-based SCM.
(See "What are the basic ClearCase concepts every developer should know?" for a more detailed comparison between ClearCase and git)
That means, for each git commit, you need to:
clearfsimport into ClearCase any file included in the git commit.
Create a specific UCM activty for that import.
As a ClearCase admin, cleartool protect -chown on the activity: see "Why is the owner of the clearcase activity 'nobody'" (as well as a protect -chgrp, if the CLEARCASE_PRIMARY_GROUP environment variable wasn't correctly set at the time of the import).
Note that cleartool protect affects the entire "element" (file or directory), not just one version, so you cannot record the user id that way: the next import would overwrite that id with the id of the new committer whom content is imported.
Plus, you cannot changed the initial creator (see "Changing the name of the original creator of an element")
That means you should record that information (author and creator git id) in attribute:
see cleartool mkattr.
If I did want to accurately reflect the Git user as the "creator" of the new version of the file does that mean I would need a way to run clearfsimport as that user - impersonate them?
Yes: for each commit, you would need to clearfsimport "as" (runas in Windows, as mentioned in this thread) that use, in order for ClearCase to properly set the creator (if this is a new element) or the version author (if this is an update of an existing version).
The reason I didn't mention that possibility in the first place is that I don't have access to the credentials of another user, for me to switch to for each clearfsimport.
Other import tools (CVS, PCVS, RCS, SCCS, SSafe) simply:
ignore that creator/author information entirely.
add attributes of their own for tool-specific information (like the promotion group 'PVCS_GROUP', or RCS_REVISION.
Each time, you will find the limitation similar to:
clearexport_sccs ignores information in SCCS files that is not related to version-tree structure; this includes flags, ID keywords, user lists, and Modification Request numbers
most of our other systems that need the Clearcase history use the creator to reflect who made that change
That means your other systems can rely on the user ID version, except if it is the one used for the import (in which case they would consult the special attribute recording that data from the import)
This is a follow up question to this answer: https://stackoverflow.com/a/9579131/1204799
"It is best to create root-based components"
If I have several standalone applications (which means their development and deployment are independent), shouldn't I create different VOB to accommodate them? What I'm doing now is that, I have one single PVob, which contains a few UCM projects, each UCM project has its own Vob and baseline component(a component without Vob). Am I doing it the wrong way?
Updated at Mar-7 16:29
After taking your advice, this is what I am trying to do now:
I created a single PVOB to accomodate all the VOBs
I created one VOB for each business team, which, in my company, only three teams
I created one UCM project for each application. Each business team
will host several applications, each application is rather
independent, but every application may have more than one branch for
parallel development, so there can be a lot of projects
Here comes my question:
Now several applications are sharing the same VOB, how can I better manage the baselines so that they are organized by applications? i.e. to prevent accidentally choosing baselines of another project
It is best to use multiple components within a (generically) named Vob.
Making a component per Vob is not "wrong" per say, but you need to know that, once a component has been assigned a root directory (like a Vob), you can no longer change that root, or make any refactoring.
By "refactoring", I allude to the classic case where I create a component "MyProject" (with its Vob '\MyProject'... before realizing, for example, a few months later that 'MyProject' has actually a server and a client modules which could benefit from a separate history: I should have defined two components and not one.
With the "one vob per component" model, I have no other choice that to create another Vob: I cannot refactor, ie I cannot make a subdirectory within my existing component, and define a second component there.
With the "multiple components per Vob", I can:
rename my first component as "MyProject_Server", with its root directory '\MyVob\myproject' (which remains unchanged: you cannot change the root directory of a component once created),
make another component within the same Vob: "MyProject_Client", with a root directory '\MyVob\myproject_client'.
The main advantage is about scale: you can define many (hundreds) components within a Vob.
But you shouldn't define hundreds Vobs, because of the sheer number of processes (vobrpc_server and vob_server) required to manage the access to said Vobs.
If you create several components per Vob, that won't have any influence on the baseline choice for each project UCM.
Ie you would have as much risk of choosing the baseline of the wrong component, whether those components are a full Vob or are part of a Vob.
You would simply separate those components in different UCM projects, and manage each component baselines in those UCM projects.
There are two scenarios:
- We have created a number of components each in their own vobs and realize now we prefer to keep them within a single vob
- We have created a component inside what ends up being the incorrect vob.
In both cases, the vobs are UCM vobs (CQ enabled) and have had projects, development activities delivered and baselines created, etc.
Our objective is to reorganize the components and code into the desired location.
Rational support indicates there is no method to achieve this:
Move UCM components between PVOBs
Do you have any strategies for accomplishing this while retaining the relevant information?
The simple approach would be to extract the current baseline and check that code into a new component in the correct vob as a new baseline, then obsolete the component in the old vob. Any other suggestions?
We are using Clearcase 7.0.1.1
Those reorganization processes always involve, with UCM, to duplicate the few latest baselines of those components into the new UCM destination component, and then keeping the old history.
(with CC7.0.x as well as latest CC7.1.2)
That is why I would suggest to lock the old components/streams/projects, but not to obsolete them, in order for the version trees of the old elements to still be visible (for reference).
Note that moving an element between components is possible is the "new ClearCase" called Jazz VCS, part of RTC -- Rational Team Concert --, as explained in this thread: "Team > Move in Repository" (albeit only for top level directory).
That is why the technote you reference states (for ClearCase refactoring between components):
The decision was made by Product Management to exclude the addition of this feature from future upgrades and releases due to the significant architectural changes required to implement the solution.
It will stay that way forever with ClearCase, since ClearCase has been rewritten already... but as a module of RTC.