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.
Related
I need to modify a Simulink project stored under clearcase. From this project I must generate the C code, but this not the problem. The problem is that all generated files (*.c and other) are saved into clearcase and the code generation delete some file without overwrite the old version with new. Fortunately seems only for files different from *.C but in any case under clearcase (I use a windows client) I found in correspondence of deleted file:
the file name
three colored question marks
I think that clearcase has the information regarding the file stored but is not able to allocate this.
Now I need a command/script for CC which help me to found ALL removed files from the view because the project structure is very complex and a manually search is hard.
Thanks for any suggestion
"three colored question" marks means "checked out but removed", as in this example (you can recover from it by reloading the snapshot view)
If an automatic process is generating or deleting files in a snapshot view (it wouldn't be able to do the same in a dynamic view), then you should end up with a bunch of hijacked files (as identified in a snapshot view).
You could check them out and check them in.
For the files that need to be deleted, you can follow "What's the “proper” way to delete files from a ClearCase snapshot?".
But both process are manual and doesn't scale well.
There are two viable options:
1/ Don't version what is generated (you can re-generate it at any time)
2/ If you must version what is generated, then:
generate it outside of the snapshot view
use clearfsimport to import the result of that generation into the snapshot view: that will checkout the right files and will delete the files that are no longer generated.
That would be the right solution for "w I need a command/script for CC which help me to found ALL removed files"
I recently started usage of clear case tools for maintenance of code in better way. But after some days my "Company" forgot to take licence from IBM as result I cannot CHECK-IN my code into clearcase. To continue my coding i created a separate folder in other drive and copied code solution in that folder. I and my colleague modified around "9865" files of solution within "45" working days. Now a "Company" borrowed a licence for me and I able to access code clear case tool successfully.
Problem is:
How to check in my "9865" files into clearcase in better way?
I tried:
Copied all solution into Snapshot view folder location. but, all
changed files are showing "hijack".
The best way is to use clearfsimport: that will automatically checkout, and import your 9865 in one command.
Make sure to update your snapshot view first, in order to restore its original content.
Then clearfsimport those files.
clearfsimport -preview -rec -nset /path/to/sourceDir\* </myview/VOB>
The clearfsimport command will detect the files added or modified, and do the checkouts for you.
If you are using an UCM view, set an activity first.
The source from where clearfsimport does that copy can be any regular folder.
I need some help on how to collect all information from ClearCase and tar or zip it, and store it in a provided space. we have migrated major baselines from ClearCase to different SCM tool .But we still have ClearCase. we want to capture all version, change, baseline, etc (basically capture everything but not the SCM tool itself) and zip it or put it in a flat file or so. this is just for historical purposes, so that tomorrow if someone wants to know what was in the ClearCase then they can see. so ,is there any idea?
The reason this doesn't exist (as far as I know) is in the nature of ClearCase (compared to a revision-based VCS tools).
It is a file-based VCS:
You create a new version for each file you change (instead of a unique repository-wide revision)
You create a label on each file you want to label (instead of a tag referring to a revision or a commit)
You create a branch for each file modified in that branch (instead of a single directory for SVN, or branch for other VCS)
...
That means you wouldn't simply export revisions/labels/branches with ClearCase. You would export them for each file: it doesn't scale well and would take too much time and space.
Migrating major baselines is sensible course of action that I have recommended before.
But for the rest, I always put a ClearCase instance as a way to explore the full history/events in case in is needed, while the recent history is managed in the new VCS tool.
Storing that as a flat file you could read without ClearCase isn't, again as far as I know, available.
Hence my previous "vobstore-reformatvob" proposition.
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.
I'm thinking of Mask as in a circuit Mask (I think)- let me explain with a handy chart
The common source would be physically in c:\source
Instance A would be physically in c:\instanceA but initially have nothing but symlinks to everything in c:\source
Instance B would be physically in c:\instanceB but initially have nothing but symlinks to everything in c:\source
As you made changes to Instance A and Instance B, you would have create a mask that would hide files from CommonSource if they were deleted from the Instance folders and create a new physical file in the instance directory if an existing Common Source file was modified.
New files would live in the instance folders but never make it back to the Common Source.
This type of setup would be very useful for a project where I want to do many different types of small tweaks to multiple instances where distinct threads would work on distinct instances.
I know about symbolic links but they fall short in the case of modifying a file.
Is there anything that can accomplish this? If not, should I try to make this and patent it? Seems like a good idea to me.
I would be on Windows Server 2008 or later.
Fearing I'm stating the obvious, but git is one tool that can be used to achieve this behavior.
Make your "Common Source" a git repository
Clone the repository twice to "InstanceA" and "InstanceB"
In each instance, check out a new, unique branch
As changes are made in "Common Source" you can merge those changes into "InstanceA" and "InstanceB" while maintaining the "MASK" (changes to the branch) you've created for each.
This has the added benefit of allowing changes from "Common Source" to be pulled as you wish instead of having changes to "Common Source" pushed out to each instance (something I imagine would be less desirable and more prone to error).
You're looking for a union mount. Unfortunately, I'm not aware of any implementations for Windows, but there are several available for Linux, notably UnionFS.
In general they are used for making a read-only filesystem look like it's read-write: typically on live-CDs.
Since Windows 7 you can use libraries, which will allow you to include files from more than one physical location.
Windows 7 also include VirtualStore type of folder (for example, when creating or modifying a file in Program Files folder, it will actually be created in a user specific folder:
C:\Users\user\AppData\Local\VirtualStore. However - I don't know how you can create this type of folders yourself, and also, as far as I know, you can add and modify files, but not delete files in that way.
You'll want a versioning control system that supports per file checkout and permissions. Then you just need to set up a simple API converter that takes file-system commands and converts them to versioning control commands.
Delete -> disable permission to access file.
Directory commands should look for local copies and things you have permission to access.
Open -> grab local copy, on fail check-out file from repository.
Save -> disable permission, save local copy. //Avoid duplicates being seen.
Close without saving -> if permission to access from repository, delete local copy.
((By the way, this storage optimization seems somewhat spurious for versioning. Disk space is relatively cheap.
If your interest isn't in versioning, I'd suggest looking into separating out the information you would potentially want as volatile and creating configuration files for each branch. This, of course, requires a predictable pattern to the changes.))
IBM Rational ClearCase is version control system which does file-mask-like behaviour. It is known as MVFS: MultiVersion File System and can be mount to a workstation like a ordinary network drive.
ClearCase server (aka. VOB) you can store several versions of the same file, each on different code branch. The sets of files visible by user are called views. Each view has a configuration (aka. configuration specification), which defines what files and versions are visible for current user. Typical file looks like this:
# From wikipedia: http://en.wikipedia.org/wiki/IBM_Rational_ClearCase#Configuration_specifications
# Show all elements that are checked out to this view, regardless any other rules.
element * CHECKEDOUT
# For all files named 'somefile', regardless of location, always show the latest version
# on the main branch.
element .../somefile /main/LATEST
# Use a specific version of a specific file. Note: This rule must appear before
# the next rule to have any effect!
element /vobs/project1/module1/a_header.h /main/proj_dev_branch/my_dev_branch1/14
# For other files in the 'project1/module1' directory, show versions
# labeled 'PROJ1_MOD2_LABEL_1'. Furthermore, don't allow any checkouts in this path.
element /vobs/project1/module1/... PROJ1_MOD2_LABEL_1 -nocheckout
# Show the 'ANOTHER_LABEL' version of all elements under the 'project1/module2' path.
# If an element is checked out, then branch that element from the currently
# visible version, and add it to the 'module2_dev_branch' branch.
element /vobs/project1/module2/... ANOTHER_LABEL -mkbranch module2_dev_branch