At our work, we are forced to use Clearcase UCM as our central repository (specifically for labelling/baselining, builds and code reviews), but our team wants to use Git as our real SCM system.
What we want to achieve is essentially a scraping service that takes the commits as they are pushed to our central Git repo, and push them on to a Clearcase VOB that is read-only as far as the development team is concerned, including important information such as the comment and the user name (exact date/time matching is not important, but getting the user correct is).
Our centralized Git server has been configured (using the excellent scm-manager) to accept Windows domain users and passwords, and our Clearcase servers use Windows domain accounts, but I am unsure how a scraper service would "impersonate" the correct user so this information is duplicated correctly in Clearcase.
I thought the chevent command might hold some promise, but that only gives access to the comment.
Is there any way to amend the details of a Clearcase event record once it is in the database, in particular the user-name? Or is there a better way to do this?
Again, we don't need a bi-directional bridge - all access to the Clearcase VOB as far as code commits is concerned would be through the scraper.
ClearCase is a file-by-file SCM, not a revision-based SCM.
(See "What are the basic ClearCase concepts every developer should know?" for a more detailed comparison between ClearCase and git)
That means, for each git commit, you need to:
clearfsimport into ClearCase any file included in the git commit.
Create a specific UCM activty for that import.
As a ClearCase admin, cleartool protect -chown on the activity: see "Why is the owner of the clearcase activity 'nobody'" (as well as a protect -chgrp, if the CLEARCASE_PRIMARY_GROUP environment variable wasn't correctly set at the time of the import).
Note that cleartool protect affects the entire "element" (file or directory), not just one version, so you cannot record the user id that way: the next import would overwrite that id with the id of the new committer whom content is imported.
Plus, you cannot changed the initial creator (see "Changing the name of the original creator of an element")
That means you should record that information (author and creator git id) in attribute:
see cleartool mkattr.
If I did want to accurately reflect the Git user as the "creator" of the new version of the file does that mean I would need a way to run clearfsimport as that user - impersonate them?
Yes: for each commit, you would need to clearfsimport "as" (runas in Windows, as mentioned in this thread) that use, in order for ClearCase to properly set the creator (if this is a new element) or the version author (if this is an update of an existing version).
The reason I didn't mention that possibility in the first place is that I don't have access to the credentials of another user, for me to switch to for each clearfsimport.
Other import tools (CVS, PCVS, RCS, SCCS, SSafe) simply:
ignore that creator/author information entirely.
add attributes of their own for tool-specific information (like the promotion group 'PVCS_GROUP', or RCS_REVISION.
Each time, you will find the limitation similar to:
clearexport_sccs ignores information in SCCS files that is not related to version-tree structure; this includes flags, ID keywords, user lists, and Modification Request numbers
most of our other systems that need the Clearcase history use the creator to reflect who made that change
That means your other systems can rely on the user ID version, except if it is the one used for the import (in which case they would consult the special attribute recording that data from the import)
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 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.
I found "Suspend Change-set" in RTC to be very useful, and since we're working with ClearCase as well (dozens of users) I'm wondering if that feature is also available in ClearCase as well.
If not - could it be generated by script/trigger/hook ?
We use UCM, and I'd like to explain my question:
if I have to deliver and I want to skip delivering one activity, I can decide not to deliver it (if no dependencies...) , so my question is regarding working on my current stream: Is that possible to "suspend" an activity from my current stream ?
Thanks in advance
Simply put, not easily.
RTC is basically ClearCase rewritten from scratch, and the "suspend" mode (also called stashed or shelve) takes advantage of the notion of applying a changeset (to any state of a repository)
The UCM changeset are a list of versions of files. Each version is tied to its predecessor, and you cannot easily remove it (unless you do some negative or subtractive merges), and then re-apply them later.
That being said, Reuven just contacted me this morning, because he had files in checked out in a snapshot view on a Stream which he wants to rebase (similar issue to your deliver problem).
A possible way to do that is to create another view (dynamic one), which you can use for your rebase, and then go back to your snapshot view and update it: it will detect the updated config spec (following the rebase) and will not erase any of your currently checked out files.
On the checkin, those files will be merged with the updated version.
When I check out a file in ClearCase it asks me if I want to check out the file "Reserved" or "Unreserved". What are the differences between these types of checkouts and when are the appropriate times to use them?
As mentioned in "What are the basic clearcase concepts every developer should know?", ClearCase support a locking mechanism which is both:
"pessimistic": reserved checkout doesn't actually prevent other people to do their own checkout, but they will have to wait for the person who has the file checked out as "reserved" to do the check in: nobody can check-in until that person does the first check-in (then each other user will have to merge his/her version with the latest checked-in file)
Note: a "reserved" checkout can release its lock and be made unreserved, either by the owner or the administrator;
"optimistic": unreserved checkout which means (if nobody use a reserved checkout on the same file): the first one to check-in can do it without any other operation, the other ones will have to merge their work with the latest checked-in file.
In term if usage policy:
Usually, reserved checkout is fine since it allows you to make your changes with a "high prioritization": they have to be taken into account first.
For local modifications which don't have to be checked-in right away, an unreserved checkout is enough.
For local modification which don't have to be checked-in at all, hijacked file or eclipsed files are enough (so, no checkout at all)
Notes:
A cleartool checkout/checkin is not the same as:
svn checkout/git checkout, which are updating a working repository with the content of a revision/commit, as opposed to checkout a version of a file: set of files vs. one file.
"checkin": svn commit/git commit which registered changes of possibly multiple files to the repo (remote for SVN, local for Git), as opposed to creating a new version for one file.
Git itself would not have "file locking" (reserved checkout). Only system using Git might offer that feature, like Git LFS.
How Can I Revert to Earlier baseline? We have a UCM parallel development(multi-stream) project. Each developer have a snapshot view on Project's Integration stream.
Developers want to see earlier version of the application in their snapshot views so They can debug early version of application to find bugs.
When I want to change an existing snapshot views's foundition baselines, clearcase does not allow me. So How Can I do this?
Since you employ the term Baseline, I will assume you are using UCM.
On a stream, you can not revert backward a baseline.
One possibility is to make a parallel stream, with the desired baseline as foundation: this is the quickest way.
After changes on this new stream, you can make a new rebase to change the foundation baseline, but only if that new rebase is using a more recent baseline from the parent stream (not an older baseline)
For your specific need, I would recommand a non-UCM snapshot view with a simple rule
element * thePreviousBaseline
In order for the developer to have:
his/her current UCM view for development (always set on the LATEST of a branch associated to a stream)
a second snasphot view set to whatever baseline he/she needs.
That second snapshot view is completely not-related to the UCM project and takes advantage of the "full" nature of the baseline (do check that your baseline has been put as "full", not "incremental". If it is "incremental", simply change its type and upgrade it to full)
So, beside your current snapshot UCM view, you can create anywhere you want a non-snasphot view:
cleartool mkview -snap -tag mylogin_myComponentname_csl_snap -vws myPathToViewStorage myPathToRootView
cd myPathToRootView
cleartool edcs
[add the selection rule: element * myOlderBaseline]
[add the load rule at the end: 'load /myVob_Including_MyComponent]
[save, type 'yes']
That is fine for consultation/execution, but if you need to patch (that i is to write, check out and in some files), then I would recommend one UCM stream per baseline to be patched.
That way, the stream clearly represents the patch effort for a given baseline. There should not be too many of them, unless you put into production a new version of your application every five minutes... which is not advisable ;)
So to summarize:
the non-UCM snapshot view is unique and serve for a quick consultation/debug of one older baseline at a time.
for patches (source modification), you create a parallel stream properly named, with the correct foundation baseline, and then a UCM view on it. You can not only debug but also fix some bugs in an activity, the deliver that activity to the main Int stream if that bug need to be retro-fitted on an higher stream.
(note: all bugs do not always need to be delivered: they can be obsolete when compared with the current state of the development)
The way I have solved this problem is by making another Stream, a child Stream of the Integration Stream. The easiest way to create this Stream is to open ClearCase Project Explorer (not Rational ClearCase Explorer) and navigate to the Project and then the Stream in question. Right click on the Integration Stream and select "Create Child Stream..."
Click "Advanced Options" and select a baseline for each component. Do this by selecting the component and then selecting "Change..." and selecting the specific baseline you want to see. You probably want to select "Prompt me to create a View for this Stream." Select "OK".
Any developer can do this. You don't need to be a VOB owner or Project or Stream owner.
Well, it depends. Actually, the answer lies in setting up your config spec to point to the proper files. Your config spec tells your view which versions of elements to look at. But how you do write it depends on your project's approach to baselines. Did you apply a label to mark that baseline? If so, and if you only want to read and not checkout anything new, your config spec can be as simple as
element * <LABELNAME>
If you didn't use labels, you can also set up your config spec to show you files based on dates. It gets more complicated the more rules you need to add to constrain your element choices. If you have more specifics, I can try to elaborate on what rules you might need. Otherwise, I would read the manuals that come with ClearCase. If you view the Extended Help from ClearCase Explorer, and then do "Viewing Rational ClearCase Manuals On-Line" it should give you some links to the Command References. This is where I go whenever I need to modify my config spec in some new way.
Also, note that we only use dynamic views, so I don't know if snapshot views work differently.