I have been tasked with researching how to improve the way my company handles version control.

Background

Currently we use Borland StarTeam, which has some issues. Apart from often being difficult to use, the number of tools (IDE support, code review, ...) which support it is very low.

Our company has something like 40 developers but we work with a lot of different projects. A given project usually has something like 3-6 software developers working together. Our projects range from (mostly) embedded systems and FPGA development to desktop applications.

The current work flow is heavily centralized with one "view" (which is close to a branch in StarTeam language) that everyone in the project works on.

One of the projects use multiple views in the following way: There is a platform view where no development is done. This view then has two sub views for two specific products that share most code (via the platform view) but is dissimilar enough to be kept apart. All development is made in the two product views and sometimes code from a product view is promoted to the platform view (which is then automatically available for the other product).

Another project seems to use a main view and a feature view when there was a major feature addition.

We usually have to support software for a long time and provide software updates.

Some of our products have a large number of different versions. The different versions will share most code but some parts are and must be distinctively different.

Developers use both Windows and Linux on their development work stations.

Idea

My idea is to switch over to use a modern DVCS. The work flow I am considering is where each project has a number of public branches which each developer can clone and work on. Each project could then determine if everyone can commit freely, or if we should have some kind of gate keeper system where code needs to pass a human or automated build system before being committed to the public branch.

My idea on the branching setup is to use release and feature branches as in the following scenario:

Let's say we start with development and finally ship version 1.0 of our product. We then fin开发者_运维百科d that we want some more features so we aim for a 2.0 release and start a new branch for this. While working on the 2.0 release branch we can still do maintenance on the 1.0 branch leading to the release of version 1.1, and so on.

While working on the 2.0 branch we discover a security problem which is fixed. Since it is available in the 1.0 branch as well that code is backported to the 1.0 branch as well.

Sometime in the 2.0 branch it is discovered that some parts of the system really needs to be completely redone to be able to create feature X. A new public 2.0-feature-X branch is created and worked on. When done, the work in that branch is merged back into the main 2.0 branch.

Actual questions

Hopefully you are still reading at this point :)

Is the above work flow (release and feature branching) a viable option? Are there pit falls to look out for?
In the scenario where a product has a platform branch and multiple product branches, what is the best way to handle this? Would creating a master branch and the product branches work? Is there a problem when two product branches diverge? How much can they diverge?
Have I missed something? I mostly see VCS from a developer perspective so I might be missing stuff that is important from the perspective of a configuration or release manager.

For your second question, I think you can SHARE the platform related code and "most code" shared by different products, and only BRANCH the source code which makes the products "dissimilar". With Share, if an item is modified in one project, the changes will be reflected in other projects simultaneously. With Branch, the file and its counterparts are independent.

So, the two product branches can be diverged as much as you need.