My ClearCase storage location has something like viewname.tmp folders, I believe they got created for my views.
I would like to know how can I delete those .tmp folders from my storage location (eg : \\server1\views\username).
If I do with delete button then "Access denied" message is coming.
A view storage ending with .tmp (/path/to/myview.vws.tmp) is only created during a rmview, in order to make the view storage directory immediately unavailable.
It can linger on if there some sort of conflict due to:
an anti-virus software (see this technote)
a cross-platform access (windows => linux through samba, as described in this thread)
If the lsview myview states the view doesn't exist anymore, you can safely get rid of that view storage once you figured you what is blocking it from being deleted.
Or you can also simply leave it here: it won't harm the creation of new ClearCase views.
Related
My Project is using IBM ClearCase as version control tool. I recently checked in some of the files, modified them and even checked out the modified files.
Next day when I try to check in some of the files, I am getting the following error :
the property is not available locally: stream
and
the property is not available locally: current-activity
Is there any way to resolve this error? I am stuck
I recently checked in some of the files, modified them and even checked out the modified files.
You actually checked out files, then modify them, then check them in.
You check out in order to make a file modifiable.
the property is not available locally: current-activity
The exact error message is actually:
The requested property 'current-activity' is not available
See this IBM technote:
Cause
The information within the .Rational folder had become stale or corrupted.
ClearQuest database connections require refreshing as they are no longer seen.
View tag (as stored in the registry server) is no longer visible on the Change Management (CM) Server when performing an Cleartool lsview.
This issue can also occur if the region used does not hold the right VOBs any longer. While trying to create new Views or change load rules the VOBs are missing. This happened due to a changed region map file.
So it depends on your OS, version of ClearCase, integration or not with clearquest.
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
I would like to reload a view (which was created previously) instead of creating a whole new one.
Two scenarios:
1 - Hard drive crashes and the local view isn't there anymore.
2 - A new laptop is set up with ClearCase.
In either (or both) of these cases, can a view be restored on your local drive? Or does the view have to be removed and then create a new one? I would rather not have STREAM_2_int and STREAM_3_int if I can get away from that.
(Side question: If someone has a desktop and a laptop, can they use the same view on each, or is it only one for each computer?)
Yes, for a snapshot view, provided the ClearCase view storage (the .vws directory) isn't on the same workstation than the view itself.
The only file needed to make a directory a root directory of a (previously created) snapshot view is the hidden file view.dat.
See the IBM technote "Regenerate the view.dat file"
And the perl script (packaged within any ClearCase installation) used to restore that view.dat file is <ClearCase>\etc\utils\regen_view_dot_dat.pl -tag <view-tag-id> <view root directory path>.
Example:
C:\source>ccperl c:\Rational\ClearCase\etc\utils\regen_view_dot_dat.pl -tag aSnapViewName .
rgy_view_uuid: "d17190d381de4ce89757d5465eb41f2c".
creating ".\view.dat".
C:\source>type view.dat
ws_oid:00000000000000000000000000000000 view_uuid:d17190d381de4ce89757d5465eb41f2c
Again, that can only work if the view storage \\shared\path\to\aSnapViewName.vws is in a shared path accessible from the workstation or from the new laptop.
I'm using only CCRC - I don't have ClearCase locally installed.
I use CCRC Version: 7.1.1 Build id: 7.1.1.03.00_2010C.D100803
I'm working with a mature user of ClearCase - they have hundreds of work streams in a complex child parent relationship tree. When I create a view or stream CCRC offers me a picture of this complex tree and the location of my view (or stream if I'm creating a stream).
However, once my local view is set up there appears to be no mechanism for checking the location of any views. CCRC menus which 'show ClearCase view configuration' only show the load rules (i.e. which VOB's I'm currently selecting).
Another post to Stack Overflow tells me that '.ccase_wvreg' lists the local file paths where local copies of the files are stored. But '.ccase_wvreg' doesn't show the logical name of the views.
So how does CCRC find a map the logical view names and their configuration?
Is there another file I can examine (or other work around?) which would show me the complete view configuration.
The only workaround I have today (other than being incredibly careful and keeping png images of the stream as I set it up) is to commence the process of creating a new view or stream and retrace my steps.
Its surprising that being able to confirm the location of a view is so difficult - given what happens if one mistakenly checks in or deliver to the wrong stream!!
The CLI (Command Line Interface) for CCRC might be able to provide more information, espcially regarding the config spec of your view, in which there should be mentioned the name of the associated Stream.
catcs [-username user-name][-ser/ver server-url][-pas/sword user-password]\
[-tag view-tag]
But check first in the properties of the view. It can also include that information.
I see .copyarea.db files popping up in my ClearCase snapshot directories. I understand that deleting the file may cause some problems. How can I get rid of these files safely?
All CCWeb views have a storage stored at the CCRC server (which in turn communicates with the VOB server).
That differs from classic ClearCase views, where the view storage is either on the user's computer, or in a close View Storage server.
Since the clients using CCRC cannot always directly access that view storage (on the CCRC server), it needs "local" view storage, which are defined within the CCWeb view, with the .copyarea.dat and a .copyarea.db directories.
Since you are not the first to getting rid of those directories (.db and .dat), CCRC 7.1 now allows for .dat directory to be restaured, allowing then ClearCase to reassess the status of each file, keeping relevant information in the .db storage directory.
The first google result about .copyarea.db suggests that deleting those files will confuse ClearCase, causing it to think that your files are hijacked.
The .copyarea.db is removed by ClearCase after I add all the View Private files in a snapshot directory to source control. It makes sense--ClearCase needs the .copyarea.db file to avoid interpreting the copied files as hijacked, but checking them in removes that ambiguity, so ClearCase no longer needs .copyarea.db and deletes it.