Could anyone explain what is a Evil Twin and Subtractive merge in Clearcase?
Evil Twin
An Evil Twin is an element that you have removed (using rmname) and want to re-add, but it's 'evil twin' exists in previous versions of the directory.
You have to remember that each element had a unique ID, so you are attempting to add an element with the same name - but with a different UID. This is not allowed.
The best way to deal with an Evil Twin is to relink the newest version you can find of the existing element to the new version of the directory. You can then make a new version of the element and replace the data within it.
Subtractive Merge
A subtractive merge is the opposite of a selective merge.
A selective merge (the default, bog standard merge) adds the changes from another element version into your checked-out version.
A subtractive merge attempts to remove the changes made in a different version from the version you have checked out - because it's a bad version, you've made mistakes in it etc.
IBM has a nice article on substractive merge.
A subtractive merge can be performed to exclude or bypass bad versions on a branch without actually removing the bad versions.
Cleartool merge using the -delete option will allow a user to merge from the last known good version to a new version on the same branch which excludes the work done in the versions identified as bad versions.
This merge must be performed from the command line, it does not create a merge arrow, the arrow can be created manually.
This will work for file as well as directory
But you need to realize that merge is about a file or a directory, not about a directory "and everything in it".
To merge recursively, take a look at findmerge.
You can want to merge only directories (since they are always merged first, to determine the actual list of files to merge!), as in this IBM article
% cleartool setview major_vu% cleartool findmerge /vobs/vob1 /vobs/libvob2 –type d \
–fversion /main/LATEST –merge
you may also do the merge from the LATEST version of a branch or from a tag:
findmerge . –fversion /main/rel2_bugfix/LATEST –print
findmerge . –ftag rel2_bugfix_view –whynot –print
Note: the -print is always a good idea before replacing it by '-merge -gmerge', in order to get a preview of what will be merged. But if directories are involved, it will only print that 'directory X' needs to be merged, not the exact list of files.
For evil twins, check out the IBM article. Case sensitive issues can be a real pain to deal with and create some evil twins without you realizing it...
Related
I want to get list of files and directories affected by specific commit. I have no problem getting the commit itself but I rather don't know how to get affected files and directories.
Just to make it clear I need something like this:
file x - deleted
file y - added
file z - modified
Git is snapshot-based; each commit includes a full list of files and their state. Any notion of "affected" files needs another commit to compare it to. This is commonly done against its parents, which seems to be what you're asking about. You can figure out which files are different between two commits (or more exactly, their trees) by using the git_diff family of functions.
You can find an example of doing so in the examples listing for libgit2. There is also a more general annotated diff example. The second link also shows how to list individual files as well as their contents, if you need that. Check the reference for a a full listing of available function to work with diffs.
Note that this won't give you affected directorires by itself, as Git does not track directories, but only files.
You're looking for git diff.
The same function exists in libgit2, and the documentation for it is here.
If you're analyzing older commits, "git diff [commit1] [commitAfterCommit1]" will give you a list of changes that the second commit made from the first. You could prune this output to get yourself just the changed file names.
I want to merge all files from a particular branch to main using a script or a command. Is there a way to do it without checking out each file in target or should i do each file manually.
ClearCase is file-based, not repository-based: any merge will be done file by file, and actually first folder by folder (you merge the folders first, then the files).
The easiest way to initiate a merge based on a branch is to use the cleartool findmerge, which can use a version selector, like -fve/rsion .../branch1/LATEST.
See also "To prepare to merge"
The usual approach though is to use a view or a tag to select the elements you want to merge, as I described in "How merge sub branch to main branch using clearcase command line under linux?" (using -ftag).
Note that this works also in an UCM environment, based on activities (even though the deliver and rebase commands remain the recommended merge methods).
My Requirement is regarding clearcase delivery:
I want to automate delivery(no manual intervention/no deliver failure) process:
While delivering - if there is any merge issue
1.if CC is able to merge files, its good- let it merge,
2.if CC is not able to merge - i don't want it to fail, instead lets not merge that particular file(revert merge for that file), proceed with next files.
3.List the files that are skipped, so that i can manually merge later.
i doubt we can do this in a single step, but let me know if this is possible, and process to do it.
you can click "skip all" during a merge, but you will have to resolve them in one way or another.
The easiest way is to make sure those files aren't considered for merge in the first place (see below).
But there is no native way to automate the process you describe:
While delivering, if there is any merge issue
if CC is able to merge files let it merge,
if CC is not able to merge - I don't want it to fail, instead lets not merge that particular file (revert merge for that file), proceed with next files.
List the files that are skipped, so that i can manually merge later.
You would need to write a script to manage those case, and even in this case it wouldn't work for an UCM merge (deliver/rebase), which won't complete until all files have been merged (hence my "red arrow" suggestion below)
That script would basically take the output of a cleartool findmerge -print (to get all directories/ files to merge), and then merge first the directories, and then the files one by one, applying the policies your are afer.
for making sure a certain file is always ignored
for the current merge:
You can simulate the merge by displaying the version tree and right click on the source version: "merge to" and select "do not merge, draw the merge arrow" (red arrow, which represents a merge arrow, as seen in this illustration).
The idea is to trick the current deliver into believing that this file has been merged even though you haven't do any modification during that merge (you just have drawn the red or merge arrow between the source and destination version).
for the future merges:
You can change the merge manager associated to a type of file in order to never merge it.
See "Handling Binary Files in IBM Rational ClearCase", which explains how to create a new special type manager:
You can then apply that merge manager to a specific file with cleartool chtype.
initially i tried below commands to get the list of file to merge(file names, activities are renamed to avoid confusion):
cleartool findmerge activity:a#\a_pvob activity:b#\a_pvob -fcsets -ftag Accept_deliver_stream -type d -merge -log c:\temp\am.log
cleartool findmerge activity:a#\a_pvob activity:b#\a_pvob -fcsets -ftag Accept_deliver_stream -type f -print -log c:\temp\af.log
so it returned list of commands to af.log file, when i am trying to execute those commands, it just hangs even after one hour, one command is:
cleartool findmerge M:\WM2011_DEV_INTG_WMOSBUILD_01\WM08\CPP\base\foundation\general\invupdates\InvUpdate.cpp -fver \main\Mainline_Int\WM08_Integration\WM09_Integration\WM2010_DEV_INTG\MAIN_WM_Int\WM2012_IND\9 -log NUL -merge -cqe
I have checked in the same file (filename) twice in 2 different branches (say, development and release).
This breaks just about anything, so I want to take 1 version and "properly" copy/merge it to the other branch, later merging in the lost changes manually (from a backup). Then I would lose history for 1 file but at least the 2 files would be connected again.
How to do it?
Also note, since the connection is broken, I cannot mere, also, when doing a Version Tree, both files have different version trees. (It is not 2 views at different files in 1 Version Tree, like is the normal/correct case.)
Also, I assume the problem is with the folder having some kind of a reference to 2 different files, but somehow, I cannot edit the folder?!
Those are call "evil twins" (also described in that SO question)
(one less thing to worry with Git ;) )
The easiest way is to pick one branch:
remove the file from the other branch (rmname),
and to the merge.
The merge will add that same file in the other branch.
That process (rmname + merge) is illustrated in "Clearcase: How do I merge in a specific file from one view, into another, to avoid the Evil Twin scenario?"
(edit by Andreas)
Your solution worked great, I changed it for me since I noticed I have a specific case:
The file got bad since someone else renamed it... so it was not just as simple as your solution, but I had to do it "by hand", as is
Go to X:\FullyQualifiedPath (correct path in VOB)
Use:
cleartool ln FullyQualifiedName ./FileName
where FullyQualifiedName is the name as you get it e. g. from VersionTree when you say “Send To -> Copy” (something like //view, drop the file: before). This creates the link
Afterwards, you can see the desired version in the ClearCase Explorer again.
I have a big named branch with a lot of changes. Some of these changes are non-destructive so I want to pick these specific files out first, and merge them with default as soon as possible. (Then later, the destructive changes are merged as well.)
In Git I would create another branch and squash all changesets outside of the index, then I would add the specific files to the index and commit. After that, I could merge this temporary branch with master so master has a clean commit with only the non-destructive change. I don't know how to do this with Mercurial.
You can use hg cat to grab the contents of a file as it exists on any particular branch, and replace the working copy version with that.
This isn't technically a merge, but since you're replacing whole files you shouldn't have too much of a bad time merging things later:
for example, to grab myfile.c form branch somefeature, and replace the working copy version, do:
hg cat path/to/myfile.c -r somefeature > path/to/myfile.c
note that this completely replaces the working copy file so make sure you have no outstanding changes first
I think mercurialqueues is what you want. With mq you can turn any changeset into a patch and any patch into a changeset. So taking a changeset converting it to a patch deleting the chunks out of the patch that you don't want and then applying it to whatever branch you want. This is a fairly complex operation though and requires a certain amount of discipline on your part. So I would try to nail down your workflow on a test repo before trying it on code you care about.
As far as I know, Mercurial doesnt any have tools to split changesets. If youre lucky, all the changes you want are in separate changesets and then you can use the TransplantExtension. I think it can be compared to Git's cherry-pick but I havent used git much.
You can also use hg diff to manually commit the changes to a certain file to a new branch. Use the rev range to mark your entire source branch:
hg diff myfile -r startrevision:endrevision
The output can be treated as a patch. Do this for each file you want and commit them and then merge. Skipping the destructive changes. You can also, of course, do this multiple times of a destructive change is in the middle of a revision range.
Having said that what youre trying to do isnt something mercurial was built for. That hardcore history editing is more Git's area (note that its just my opinion). Keep your stable changes and destructive changes in separate changesets (and maybe even in separate branches). I use transplant, rebase and strip to move changes around. When its all done, they are merged and properly pushed.
Oh, and check MercurialQueues. I havent used it myself but Ive seen it do some crazy stuff. Maybe its capable of doing something along the lines of what you want.