Hi I wanted to know if there is a way to do cleartool findmerge without creating .contrib files. Its a nuisance to have to remove them after merging.
It depends on your version of ClearCase and type of merge, as detailed in this technote:
The .contrib files are generally used to compare the file's previous contents with its new after-merge version; moreover, these files are view-private and can be removed.
There has been discussion around the ability to allow the end-user to disable/enable the .contrib creation; however, with UCM, since all checkouts involved in deliver or rebase activities are reserved, there is no chance of loss changes as a result of the merge.
The .contrib file, in regards to UCM, does not serve the same purpose, or hold the same significance as with base ClearCase.
Change request (RFE) RATLC00608266, was opened to improve the logic used for leaving .contrib files after a deliver or rebase operation. There is no danger for loss of data as a result of the .contrib not getting created.
This behavior has changed in ClearCase 7.0. where feature level 5 was introduced. When using the native client, contrib files are no longer generated when merges occur during deliver and rebase (the Rational ClearCase Remote Client continues to create and use these files)
So with CC7.x and for deliver/rebase types of merge (ie UCM merges), you can aboid the contrib files.
Not with CCRC or base ClearCase merges (which is used by a cleartool findmerge).
That is why that same technote details ways to remove multiple .contrib files in one command (like for /R %i IN (*.contrib) do del %i or del /s *.contrib* for Windows).
Related
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.
Recently i was asked to deliver interproject delivery.
While delivering lot of merge request was popped for even binaries.
I skipped them and did draw merge arrow one by one. It was nerve breaking work.
Is there any way to exclude binaries from being merged or some command line option to draw merge for all the binaries?
( I am using clearcase UCM)
Yes, you can change their type manager to a type with the option "copy on merge" (or never merge, if you really don't want them merged at all).
That type manager inherit from compressed_file, but would resolve any merge by copying the source version over the checked out destination version.
See Clearcase UCM is trying to merge pdf files as an example.
You also have the IBM technote: "Handling binary files in ClearCase".
So you have the choice between:
or:
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
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