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:
Related
I'm using git to version control SSIS packages and I know that SSIS generates some crazy XML that is going to badly confuse any merge algorithms.
I'd like to know if having the following line in my .gitattributes file is the correct thing to do:
*.dtsx -diff
I believe this will stop git from attempting to merge the file, which is what I would like.
Am I correct in thinking that this also stops git from generating deltas and therefore stores every change as a whole file? (and therefore, takes up more storage)
My repository also holds the source for the database schema and any other source files, so I'm thinking that switching the repo to fast forward only is not appropriate.
if you don't want files to be merged in git, you need to use the -merge attribute. That way you can still be able to 'diff'.
We also treat packages as binaries, that does imply you will need to do changes multiple times if you need to do a patch from a branch and also need it in your main tree.
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.
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).
Is that possible to distinguish if merge was performed manually or automatically?
I'm using ClearCase 7.1.2 on Windows, and I'd like to know if you can find it by watching the version tree or by any given command-line
Thank you
If by automatically, you mean: is a version created by a deliver/rebase, as opposed to a version created by a manual merge, then the name of the activity associated with that version can help:
If it starts with 'deliver' or 'rebase', it is made by a deliver/rebase UCM operation (which automatically merge all changed files from one Stream to another)
But if by "automatic vs. manual" you mean a version merged manually because there was a conflict between the source and destination version (and ClearCase couldn't automatically merge the two), then no.
The result of a merge is a new version with a "red arrow" between the source and the destination, without any indication as to how that new (merged) version was created.
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