So Someone from my team has deleted some foundation Baselines from an Integration Stream and now when people rebase their development stream many of the folders and files inside them are missing.
We can see those missing foundation baselines in the development streams of that Integration Stream.
So I wanted to know how I can add those missing foundation Baselines from those dev stream to int stream, we only have access to IBM ClearTeam explorer to do it.
we only have access to IBM ClearTeam explorer to do it.
So you still have the CCRC CLI (rcleartool) (assuming the CCRC WAN Server is upgraded to ClearCase® version 8.0.0.3 or higher)
mkbl, however, is a cleartool command only (not rcleartool) in CC8, but rcleartool mkbl does exist for CC 9.x.
You could use that to recreate your fundation baseline, assuming you can tweak a (preferable dynamic or webview) config spec to select the right versions.
The baseline still exists, so you should be able to rebase the integration stream to re-add the baselines. You may want to describe the baseline to find the stream the baseline was created in to be sure you know everything you need to know about it.
rcleartool rebase -baseline baseline1#/vobs/mypvob,baseline2#/vobs/mypvob
Should be enough to accomplish the job. If your int stream has a successor baseline as the foundation now, and the component is not read-only in your project, you'll get an error message. The error message should tell you more about why you can't do the rebase.
Project has taken so long to decide to upgrade Clearcase from 7.1.2.6 that we 8 going out of support in less than a year we now looking at CC version 9.
Does anyone have any experience or knowledge if potentials pitfalls or issues doing this.
We are using UCM CC with CQ and have seen one post describing an update in how this can work but is there anything else any one has encountered?
Common stumbling blocks include:
VOB schema version. Since you're on 7.1 already, we at least know your VOB schema is supported.
Feature level. If any of your VOBs are not at least feature level 6, you need to update them to FL6 before upgrading CC. See About feature Levels and ClearCase for more on the available feature levels.
Platform support. Between 7.1.x and 9.0, a number of older platforms were explicitly desupported, among them XP, Windows 2003, Solaris 10, Red Hat Linux 4 & 5, etc. You may have to update the OS, which may require a hardware update. You should review the ClearCase 9.0 Detailed System requirements to verify whether your server and client hosts need to be updated in order to support the new release.
Integration changes. If you are using older development tools, they may no longer integrate with the current ClearCase release.
User Interface changes. ClearCase 9 includes an Eclipse-based client called ClearTeam Explorer which has some, but not necessarily all, of the functionality from CC Explorer, Project Explorer, the vtree browser, and some merge tools. Those older tools still work, largely the way they did before warts and all.
There is a lot of work in 9.0 to make ClearCase more "thread-friendly" to allow for multithreading some server processes in subsequent releases. Some of this (view and albd improvements) should show up fairly soon in 9.0.1.
As with any large system migration, setting up a test environment would be recommended to locate any issues with tool integrations before rolling it out in production.
I now have several branches that have all been merged into the master branch:
I have yet to create a tag and officially release this edition.
So when is the best time to remove your merged branches? I noticed in TortoiseGit that when you merge the branch there is a check box for Delete Branch.
Thanks for your advice.
Depends on your workflow. But generally after merge.
A common workflow is:
merge to develop (if you have a build server, see that the build is ok)
delete local branch and the tracking remote
I am working in a project which uses Clearcase for it source code management. Many times we have come across scenarios where we want to find all files having a particular set of keywords in the checkin comments like when tracking files changed for a cahnge request.
As of now, we do it with help of Clean approach suggested in this answer Searching ClearCase for a checkin with a specific comment
But we would really like to get our hands on some utility like fisheye for clearcase so that it becomes easier to do our task
The problem is, any utility you would find would be based on the same cleartool find -exec command I mention in my previous answer (ie: quite slow)
And FishEye 2.9+ doesn't support ClearCase anymore.
Only recent version of (commercial) tools like GoMidjets Visual Annotate offers some kind of efficient search on those metadata.
We are in the process of migrating our bug tracking to Bugzilla from a really old version of track and I am running out of Advil.
We have a legacy application that has been around for a long time. Mix in the fact that our versioning management has been through a few iterations it generated a lot of different versions in the wild. To make matters worse, because of contractual limitations it is not always possible to upgrade the clients to the latest and greatest, so we must branch, fix, test and release, on the version they currently have, yielding yet another version number.
The end result is that the version combo box is ludicrously long. Lastly, for various reasons, we want to track three different version information :
the version in which the bug was found (version), the version in which we plan to fix (milestone) the bug and the version in which it has ultimately been fixed (open to suggestions). here is my problem in fact... this can actually be multiple numbers where we did a retroactive fix for some of these customers (this happens VERY often).
This is where I need your collective wisdom :
How do you keep track of these versions (found, planned and multiple fixed) in Bugzilla?
What are the best practices around linking versions and bug tracking ?
Answers
It seems that cloning the bug for each version is a good way to track, thus the target version is always tracked in the milestone as well as the fixed version, and the buggy version is always the native version.
Also to have each clone block the original bug make it a good way to trace the history back to the original submission.
Although I have accepted the answer I still welcome your input.
Often, if we need to fix something in multiple released versions (generally branches in the source code repository), the bug will be cloned for each branch so that all the commits and release status can be tracked separately. I think the only time we don't do this is when the change is not directly related to the codebase itself and cannot be fixed simply by updating our libraries.
As for version tracking in general, this has struck me as a reasonable way to do things, given that we generally only need to support 2-3 major versions (plus the trunk) at any time. If you have multiple disjoint versions that need supporting, e.g. customer-specific deployments, then things are going to be harder to track. (Arguably this is going to cause headaches in general and it would be better to unify things to a more central version theme).
I use Bugzilla to keep track not only of bugs, but also of new features, enhancements, and vague ideas. For each planned and released version, I have a Tracking Bug (something that I saw on the original Mozilla bugzilla, and found to be useful).
So if you have a bug report, you enter the bug with the version number that it was reported. Create additional bugs (one for each version you plan to fix it in) which all depend on (block) the original bug and block the version-specific Tracking Bugs.
If all bugs blocking the original bug are closed/verified (whatever your QA implements), you can also close the original bug.
I was looking for a similar feature in TFS, and while doing some investigation, I found that there is an enhancement request to manage "sightings" in Bugzilla:
"Bug 55970 - (bz-branch) Bugzilla needs to deal better with branches (implement sightings)":
https://bugzilla.mozilla.org/show_bug.cgi?id=55970
There is also a proposed design:
https://bug55970.bugzilla.mozilla.org/attachment.cgi?id=546912
For information, we are going to implement something similar in TFS 2010, with a "Bug Parent" or "Bug Master" to hold the information about the bug itself (repro steps, severity, technical info, impacted components...), that can have child of type "Bug Child" or "Sighting" that will hold the information specific to a given branch (target milestone, priority, specific information for that branch...).
We are using jira and still have this problem. I think it is a question of requirements and how are versions used rather than any one tool.
Who uses versions and how do they use them?
How are versions related to milestones in a project plan?
We use a 4 dectet version (major.minor.patch.buildNO). buildNo is the SVN head revision # at time of build. Each version is stored in JIRA and issues have an affects version and fixed-in version field that's a multi select.
After a short while we have many versions. Jira does allow us to control the list in two ways
1. Archive versions (greyed out from pick list)
2. Merge versions (rolls several versions together into a new version - no undo)
We have used Archive, but have avoided Merge due to the lack of the undo. So we still have a list of many many versions.
I'm sure you could probably accomplish a merge action in Bugzilla with some scripting and time, the question is: when is it OK to merge several older versions together?
If I have released, do I need to know that I have 17 builds between start and release? Do I need to keep the knowledge of a bug being found in build 1, fixed in 2, found again in 7, fixed again 9? Or is Found in release 1.0.0 fixed in release 1.0.1 good enough?
i'm going to ask a large question on this topic later on today, but I know the basic answer already:
- Depends on how your team wants to track things.
Implementation is fun, but it all comes down to requirements, goals and working back from user experience to solution. Which is rough when people don't necessarily know how that want to use something that doesn't quite exist in the form they'd like to use.
I have created a custom field (string) to list to version(s) (as V.M.P.B) where a bug has been fixed.
I have created also another custom field (string) to list to version(s) affected by a bug.
Doing that you are able to perform quick-search on specific version.