A few months ago we released a new utility (named “Get Real Change”) that quickly determines where the code was REALLY changed; by whom; what defect \activity it’s related to, as well as other change–related info (and this works even the change was made on a faraway branch many years ago or even it was merged many times).
Now I’m happy to announce that we have extended the utility and we now support checked-out files, so users can use it during the merge process and better understand merge conflicts.
Prior to this new version, the utility could not track checked-out files due to restrictions coming from ClearCase itself. Now we can offer a solution so you do not have to check-in the file or undo check-out anymore when you want to run this utility on a particular file. That also means that you can work with this utility at any stage during the development process – even during the merge process (e.g. when you encounter a merge conflict and you have to get the full context of code sections before you complete a merge, delivery or rebase). Users have already told us how much easier and more efficient this makes the merge process!
You can download the manual and see some examples by clicking here.
Haven’t tried it yet?
You may also find it interesting to know that:
- This utility is a great alternative to ClearCase Version Tree or ClearCase History and can save you lots of time and hard work when researching who changed the code.
- This utility is part of our Visual Annotate add-on tools: Stand-alone Edition and Visual Studio Extension. This utility is also embedded in the graphic user interface.
- We provide licenses, support and updates – contact our sales team for more details: firstname.lastname@example.org
- This utility supports a variety of file element types: text_file; compressed_text_file; xml; html; UTF and user-defined types.
- You can use this utility to automate development processes and integrate tools. This tool operates as an API layer for ClearCase. For instance:
- you can use this utility to bridge between the unit-testing, code-review or continuous testing processes and the opening defects process, enabling you to automatically assign defects to the person who initially changed the code.
- You can automatically alert developers and send email notifications when a defect is encountered on a code line they changed.
All of these advantages can help you improve quality and save delivery time.
It’s currently working for Windows. To enable it for Linux and UNIX users, contact our support team (email@example.com) and we’ll explain how to do so.