Over a million developers have joined DZone.

codeBeamer 5.7 Released: Integrator Workflows, Pull Requests with Git and Mercurial Behind Your Firewall

DZone's Guide to

codeBeamer 5.7 Released: Integrator Workflows, Pull Requests with Git and Mercurial Behind Your Firewall

Free Resource

GitHub is the pioneer of social coding. GitHub focuses solely on the Git distributed version control system, but one must not forget that Git is not the only player in the Distributed Version Control area.

codeBeamer, Intland Software's Application Lifecycle Management (ALM) platform, is the only product on the market that provides social coding in a DVCS-agnostic way, by applying the same principles to both Git and Mercurial, the two most widely used Distributed Version Control systems. codeBeamer hides the differences between them, accelerating adoption and enabling mixed-DVCS teams.

What are the most notable changes in codeBeamer 5.7, just released recently? 

  • You can create any number of source code repositories per project.
    You can even mix the version control types: you can have a project with two Git and one Subversion repositories. This enables smooth transition from the Centralized Version Control model to Distributed Version Control, gradually converting your projects and teams from Subversion to Git or from CVS to Mercurial, for instance.
  • Integrator workflows: flexible, yet well-controlled method to review and integrate source code changes.
    Project members create their own forks (copies) of the reference source code and work on these forks. When they have completed a unit of work (implemented a feature or fixed a bug) and want to propagate their changes back to the reference code, they will ask the maintainers of the reference code (the so-called integrators) to merge a commit range from their repository to the reference one. They do it by sending a "pull request", which encapsulates what to merge and why to merge it. Integrators will then review and discuss the proposed changes, and decide whether to accept or reject them. It's fast, efficient and secure.
  • Inexpensive forking, easy merging with Git and Mercurial.
    You can implement features on separate forks of the code, and merge them only when they reach a certain quality. Also, before codeBeamer 5.7 it has never been so easy to start a repository for experimental development, then drop it if it didn't work out as expected. It ensures quality and consistency, improves project agility and fosters innovation.

Useful links:



Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}