I am having a project which is to be released this month. My CC admin advised to clone the project in separate project as we want to do another parallel development.
How to clone a project from another project (from particular recommended baseline)?
If there are few more changes done in source project (Which may be done another few weeks), i need to sync it withe new project. How to achieve that?
It is not exactly a "clone": you just define a new UCM project, with at least one Strea, called by default an "integration Stream".
However, in your case, you could for your new parallel development (ie your new UCM project), use only that one "Integration" stream, in which case it wouldn't play really the role of "integrating", but would be a "development" stream.
That wouldn't prevent you, in this new parallel development project, to recreate whatever hierarchy of Stream you would need.
Each UCM project has always at least one Stream. Then it is up to you to create sub-streams as needed.
You would rebase that first empty Stream with the baseline of your choice (put on one of the Stream of the first project)
For keeping both projects in sync, you would deliver from one project to the other.
You need though to set the deliver policy "allow interproject deliver to project or stream"
Related
I am working with ClearCase UCM. We have a project that has been created as a 'single stream' Project Type.
We now wish this to have multiple child streams.
Is there a way to change this after creation? If so, how? Or does this need to be recreated?
I have looked into commands that change the project, but other than policies, I can't see if something may be related - and I can't see any related policy names - but this is fairly new to me, I just happen to have the most experience in my area.
The simple/multi-stream nature of an UCM project is determined at its creation with cleartool mkproj -model.
The "model" (simple or default) is not something you can change by policy or with cleartool chproj.
That is why the IBM help page on "Single-stream projects" says:
You may want to use a single-stream project during the initial stage of development when several developers want to share code quickly.
When the development effort expands and you need a parallel development environment, you can create a multiple-stream project based on the final baselines in the single-stream project.
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'm wondering if it is possible to create project-specific files in Clearcase. What I want to do is create files in one project, use Clearcase to source control the files, but I don't want those files to leave that porject because they don't have applicability in any other project.
For example:
I want to manage database changes in Clearcase. I plan on having 3 folders in each project (projects are created for each release of the software). The folders are "install", "update", and "backout". The install folder contains the scripts needed to build a database from scratch for the stream that I'm working in, let's say the stream is in project "13.03". The "update" and "backout" folders contain scripts needed to update and backout the changes to bring the database from 13.02 to 13.03, and vice versa.
In the 13.04 project, I'll have the same folder structure, but I don't want the contents of the "update" and "backout" folders in my 13.04 because I'll have other files that will bring the database from 13.03 to 13.04.
So what I'm looking to do is essentially create "project-specific" files/folders in Clearcase.
I'd gladly take any other recommendation for managing database changes in Clearcase. Keep in mind that the 13.03 and 13.04 (for example) baselines could be being developed at the same time.
It seems you are referring to the same project, with different versions (13.02, 13.03, ...).
If that is the case:
simply update your 3 folder according to the current version
put a baseline (if we are talking about ClearCase UCM) on the component representing your project
if evolutions needs to be done on any file of a specific version, make a child Stream called, for instance, "13.03", and update your "13.03" folders there. They will evolve in complete isolation in their own dedicated "13.03" branch.
If you have to create a new directory for each project version (which means you don't need a source control system at all, just a simple backup system), then you have no choice but to recreate each of those folders with their appropriate files in them, making new "add to source control".
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.
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.