I currently have a jacked-up delivery from a child stream to a parent in ClearCase. If I try to undo the delivery it tells me I can't because the "integration activity has checkins" or "checked in versions".
If I try to resume the delivery it says it encountered an error attempting to checkout or merge an element, but doesn't specifically tell me which one.
So I'm looking for a way to either:
Manually stop the delivery (undo all checkouts in the parent stream?)
Find out what element is causing the delivery problem (is it same as the one causing the undo problem)
or Find out what element is causing the undo problem and find a way to undo the checkin (I don't know how to do this. I tried to delete a version in the version tree, but I don't have permission).
For 3/ "Find out what element is causing the undo problem", this is easy (but not recommended): you need to remove all the checked-in versions done during the complete phase of the deliver.
And that is by far the most dangerous solution, especially if any type of activity (other checkins, baselines, ...) has been done on the destination Stream (the stream to which you are delivering file, ie the Stream with the view you are using to deliver to)
You can see those checked-in file by describing the deliver activity (which always starts with deliverbl.xxx)
cleartool descr -l activity:deliverbl.xxx#\myPVob
1/ and 2/ are linked.
A good solution to easily detect the issue is to resume the deliver graphically: open the ClearCase project Explorer (clearprojexp), right-click on the source Stream and select deliver (Baseline or Activities, to default or alternate target: it doesn't matter).
ClearCase will detect that a deliver is in progress and will propose to resume.
All you need to do is check all the files with a red circle and white cross (not the files with a yellow warning sign, those are not blocking the deliver).
Once you have one of those files, right-click on it, and select "display element merge": you will have a more precise error message that you can copy-paste.
If those files are in lost+found directory, all you need to do is to edit the config spec of the view used for the deliver, and add a non-selection rule to avoid selecting anything from lost+found:
cd /path/to/your/view
cleartool edcs
#add at the start of the config spec
element /myVob/lost+found/... -none
Then resume again your deliver, and you will see that those 'lost+found' files become ignored (with a warning non-blocking status attached to them).
If those files aren't in lost+found and are failing the deliver because of "Not a vob object <directory name>", the first check to do is to go to the parent directory of said files in a shell session and type cleartool ls: you will see their status.
In this case, the OP Ian reports them as hijacked, so it was simply about undoing their hijacked status.
He reports also having to delete (rmname) some binary files, although my answer to the question "Clearcase UCM is trying to merge pdf files" is pointing to an alternative solution (copy merge).
My recommendation: in that particular state (deliver with checkins already there), try hard to complete the deliver, not to cancel it.
Related
I am working with a tool which auto-generates a large amount of C code. The tool generates code for a batch of .c and .h files at each run. For some reason, the tool isn't smart enough to recognize when the files have no substantial changes, so in many cases it simply updates a timestamp in the comments at the top of each file. Otherwise, the file remains unaltered.
When I run git status in that scenario, I sometimes see dozens or hundreds of files changed. But as I review the changes to the individual files, most of them have no real changes - just an update to the timestamp. I have to go through each file one-by-one to determine if there are any actual changes to be committed.
Is there a way to configure Git so that it can ignore inconsequential changes such as the timestamp in the header comments? Or how might I otherwise deal with this situation?
Thanks for your help.
Is there a way to configure Git so that it can ignore inconsequential changes such as the timestamp in the header comments? Or how might I otherwise deal with this situation?
Yes; this is the purpose of a filter.
You might be familiar with git's notion of "clean" and "smudge" filters already, that's how it handles line ending conversion. When you are on a Windows computer and have Windows-style line endings in your working directory, you might set a .gitattribute like * text=auto indicating that you want files checked into the repository with "normalized" Unix-style line endings. In this case, the files will have the "clean" filter applied to convert \r\n line endings to \n style line endings. Similarly, the files will be "smudged" on checkout to convert from \n to \r\n on-disk.
You can create your own clean and smudge filters to remove (or add) data when translating between the working directory and the repository. For these files you can add an attribute:
*.c filter=autogen
And then you can configure your autogen filter, with commands to run in the "clean" (into the repository) and "smudge" (into the working directory) directions.
git config --global filter.autogen.clean remove_metadata
git config --global filter.autogen.smudge cat
(Using cat is a "noop" as far as filters are concerned).
The Pro Git book has more detailed examples of creating your own filters.
I discovered a way to address the problem of trivial changes using Beyond Compare. I will describe the process as it pertains to ignoring timestamp updates in auto-generated C files, but it can be easily adapted to other situations and languages:
Configure Beyond Compare as the Git difftool. See here for specific details about how to do this.
(Optional but helpful) Add a Git alias for the git difftool --dir-diff --no-symlinks command (for example, dtd).
Make some changes (e.g. auto-generate your files), and run git dtd to do a directory diff. Beyond Compare will open and show you a before/after Folder Comparison of your changes.
Open a Text Compare session window for one of your changed files. Open the Tools menu and select File Formats.
Open the Grammar tab, delete the "Comments" grammar element.
Add a new grammar element and give it a meaningful name such as "Generation Time Comment".
For Category, select the "Delimited" grammar element. In the "Text from" box, enter the text you would like to ignore. For example, if the timestamp in your auto-generated code starts with the string * Generation Time:, enter it into the "Text from" box. Check the "Stop at end of line" checkbox.
Click the "Save" button and go back to your Text Compare session window.
Open the Session menu and select Session Settings. Open the Importance tab.
Look for your new grammar element (e.g. "Generation Time Comment") and uncheck it. This will tell Beyond Compare to treat it as an unimportant change.
Open the Comparison tab, select Rule-Based Comparison.
Change the dropdown at the bottom of the dialog to Update session defaults.
Close Beyond Compare, and then reopen it again by running the git dtd command.
All of the files in the Folder Compare session which contain nothing but an update to the timestamp will be shown with unimportant differences. If you want to completely hide files with unimportant differences, toggle off Ignore Unimportant Differences in the View menu.
Reference: https://www.scootersoftware.com/support.php?zz=kb_unimportantv3
I try to add a file in a branch to source control by doing this:
ct mkelem -ci -nc
and I get this error:
File already exists in "other_branch" branch.
Resolution: Since this file already exisit in ClearCase you will have to, selectively, merge this file from other_branch branch to your current branch/view.
Well, other_branch is completely obsolete and I would like to use the current branch file im trying to merge 100% as is. Is there a way to communicate this to clearcase on the commandline? Like ct mkelem -force (or -replaceAnyOtherFileWithThisName) -ci -nc?
There is not many solutions, beside removing completely that element (which can be dangerous in general, except in your case, this is about an obsolete branch).
cleartool rmelem
But a "safer" route would be to try an merge that obsolete branch, ignoring all changes except the addition of that file.
That way, you don't have to 'mkelem' the same file again, you can reuse the one existing (and changing its content completely).
I am facing a following issue while adding a file to clearcase (UCM)
---------------------------
Rational ClearCase Explorer
---------------------------
Error adding 'M:\Myviename\Myvob\Myproj\Implementation\DataSource\Deployment\BOM\SupportFiles\Service.config' to source control.
Created branch "Tm6-Proj-Dev2" from M:\Myviename\Myvob\Myproj\Implementation\DataSource\Deployment\BOM\SupportFiles\Service.config' version "\main\0".
Type manager "text_file_delta" failed create_version operation.
I tried rebase and deleted and added the file again. But facing the same. Why this occured and how to solve it?
You will find all the know cases for this error message in this technote "Knowledge Collection: Type manager <text_file_delta> failed create_version operation"
Type manager size limitation - File too large
Text files that contain binary data - Contains a '\000'
Line exceeding 8000 bytes
Corrupt source container - not the highest on its branch
The main cause is a content incompatible with a text file (line too long, or binary content).
The OP Samselvaprabu adds:
Our IT guys used the following command "chtype Compressed_file".
After that it allowed to check-in.
As they did it in my collegue system, I was not able to ask what does this mean and how it solved the issue?
It does solve the issue (and it has nothing to do with UCM): since the text_manager doesn't recognized the content of the file as text (as illustrated, for instance, in this technote), you need to instruct ClearCase to treat it as binary content.
cleartool chtype compressed_file <filename>
Pro: it allows for checkin/checkouts
Cons: you won't be able to "compare with previous version" anymore.
You might need to instruct that compressed_file to be always copied over instead of merged (see "Clearcase UCM is trying to merge pdf files")
For certain set of files, you could also modify the magic file to automate that process: see "Check in to ClearCase fails".
Which type of view are you using ? Static(Snapshot) or Dynamic ?
check if file is already there on the main.
If the file is already there on main (which means file is Versioned file) then before editing you should check-out file and then after making changes you need to check in.
If you are using versioned file and you if made changes to this versioned file then it will be a hijacked file, (you will see red+green mark for on the file in clear case explorer).
Try out once.
In Clearcase, I want to copy (fork, split) a file while preserving its history. Something like svn cp old.txt new.txt. How do I do it?
It isn't possible do fork a file in ClearCase.
If you refactor your code and split a file in two, one of them will appear as a new file and you will loose the information about who coded it. The annotate command will say the author of the lines are who splited it.
UCM or not, you cannot duplicate easily the full history of a file.
The best way to isolate an history is still to create a branch in order to make new versions to that file without impacting the same file in the original branch.
Thinking 'svn cp' should be available in ClearCase might come from the fact that, in SVN, branches are directories, and a tool like cc2svn will actually replicate ClearCase branches using 'svn cp'.
But since, with ClearCase, branches are first-class citizen, it is best to reason in term of branch than in term of copy/fork.
From the main page of cc2svn:
There is a difference in creating the branches in ClearCase and SVN:
SVN copies all files from parent branch to the target like: svn cp branches/main branches/dev_branch
ClearCase creates the actual branch for file upon checkout operation only.
Pretty simply done
Check out parent folder
Move element you wish to duplicate to appropriate location (not within the checked out parent folder)
Undo Checkout of parent folder
All the files get returned to the original folder with history and also the duplicate ones remain in the new location with the history too. Now each file can be checked out and changed individually
I have several files that I rsync'd over to the vob and they all have times 40 minutes in the future.
I tried touch, and all that does is maintain the time 40 minutes into the future from when I touch.
I guess that ClearCase is in charge of setting the modification time and is overriding touch.
Is there another way? Is there a way to tell ClearCase to stop messing up the file time?
What option did you use when adding those files to source control?
As explained in this help page:
To preserve the modification time of the file being checked in, use the -ptime option.
If you omit the -ptime option, the modification time of the new version is set to the checkin time.
The mkelem man page adds:
On some UNIX and Linux platforms, it is important that the modification time be preserved for archive files (libraries) created by ar(1) (and perhaps updated with ranlib(1)).
The link editor, ld(1), generates an error message if the modification time does not match a time recorded in the archive itself. Be sure to use this option, or (more reliably) store archive files as elements of a user-defined type, created with the mkeltype –ptime command. This causes –ptime to be invoked when the element is checked in.
Unless you remove those files and re-create them, I don't think you can change the "Created on" time.