StarTeam view/branching approach

Question

We're looking for some advice on our StarTeam configuration. We have a project that is used by two main customers. We share a common code base but we want to be able to do development for one customer at a time. Does anyone know what the best way to do this is using StarTeam?

I would think you would want to do something like this:

->Main branch (1.0)
-->Cust #1 Release (1.1)
-->Cust #2 Release (1.2)

As 1.1 is done, you would merge this code into 2.0. Same for 1.2. Then you would create 2.1 or 2.2.

Does this make sense? Just looking for some common sense configuration management solutions that would work for our scenario and would work easily with StarTeam.

Thanks.

Update: I found an ST best practices guide that contains useful info regarding this question (see chapter 5). The recommendations are inline with Craig's ST usage (see below). Note that this guide was published Dec 2003.

Answer 1

You may not want to hear this, but there is no single best way. Having said that, I will tell you what we do.

We do nearly all development in the default view. When we are close enough to releasing one version of a product that we want to start working on the next version, whenever that happens to be, we make a derived view for the version to be released. The derived view is set to branch on change.

We continue development of both the version to be released and the next version in the default view. When there is a bug fix or feature which needs to be included in the version to be released, there are two possibilities:

1. The only thing which has changed in that file is the bug fix or feature which we want in both the version to be released and the next version.
2. There have been changes made to the file which are intended to be included in the next version, but not in the version to be released.

In the case of (1), we go into the derived view, right-click the file, choose Advanced->Behavior, and change the Configuration such that the file includes the changes we've just made. In the case of (2), we check the file into the default view (so that the changes will be included in the next version) and into the derived view (so that the changes will be included in the version to be released, and, of course, only including these changes), causing it to branch.

To be clear, we do nearly all of our work in the default view. We rarely have to manually branch or change the configuration of files in derived views, because we do not create the derived views at all until we are very close to release.

This is not too far from what you propose doing for your customers, but the important point is to work in the default view and avoid having to do bulk merges up or down into the derived views. StarTeam's view compare/merge tool is just not that great. (We are using 2005; it may have improved since then.)