Howdy - I've written a piece about this branching question. For long-term
reference, I've posted it in my StarTeam blog at
starteamanddave.blogspot.com/.
Here it is for your convenience.
Branching Views for Releases
This is my personal recommendation for structuring branches to maintain
multiple releases using StarTeam. This recommendation is not necessarily
consistent with all of Borland's recommendations, but it is pretty close,
and I would argue that it is the best possible hybrid of the various
recommendations from Borland, Starbase, and customers over the years.
Project: MySoftware Major Version 1
...|
...RootViewV1
......|
......MajorRelease1.1
......|....|
......|....MinorRelease 1.1.1
......|....|
......|....MinorRelease 1.1.2
......|....|
......|....MinorRelease 1.1.3
......|
......MajorRelease1.2
...........|
...........MinorRelease 1.2.1
...........|
...........MinorRelease 1.2.2
...........|
...........MinorRelease 1.2.3
In this example, the "MinorRelease" views are "Activity Views" (see the
'Best Practices' paper by Randy Guck for more about Activity Views.)
The minor release activity views are where checkins occur.
The major release views DO NOT get checkins. They only get merged up from
activity views, and those merges only occur around releases. (Root view also
does not get checkins.)
For example, let's say that today I have 1.2.2 in production while we are
developing 1.2.3. All of our new development goes into the 1.2.3 activity
branch. Let's suppose that it is necessary to release some fixes to
production. We check those fixes into 1.2.2, cut a release from 1.2.2, and
1.2.3 is unaffected. Of course we would merge the fix forward to 1.2.3 also,
so 1.2.3 is unaffected _except_ for that merging.
When we are ready to start work on 1.2.4, we would of course, create a new
activity branch called 1.2.4. This activity branch would be a child of
MajorRelease1.2. Naturally, it is very important that we choose the best
configuration in MR1.2 as our basis for 1.2.4. To that end, we should merge
upward from 1.2.2 and also 1.2.3 to get the most current configuration on
which to base 1.2.4.
Ideally, the major release views should contain only the configurations that
we really did release, but sometimes it is convenient to merge up before
releasing in order to facilitate creation of a new activity branch.
If we begin another major release, say 1.3, then we do likewise at the top
leve, merging the latest 1.2 configuration up to the root view and then
creating the 1.3 major release branch.
If it is necessary to work on 3 or 4 or more releases, this branch structure
can accomodate by creating more activity views in the same way. Beware of
creating future activity views and then having to merge the whole world into
them. Don't create them until they are really needed.
This approach is merge-heavy, but careful study of the viewmerge command
line will help with that.
This approach, when combined with CR sharing (see my other post about that)
creates some sticky trade-offs regarding the
"set-shared-items-to-branch-on-change" behavior of the activity view. I
handle that by doing two things. First, all my activity branches are set to
NOT turn on branch-on-change for shared items. This setting is to accomodate
CRs and make them float. Files, then will float (undesirably so) if not
constrained. So, Second thing I do is use the viewmerge command only to
merge existing files. Insofar as any new files must be shared as part of a
merge, I do that sharing manually and also manually ensure that
branch-on-change is set.
This approach really really gets sticky when your developers also want
certain "common" code to float. I would recommend just putting common code
in its own dedicated branch and checking it out on its own, but my
development team is allergic to doing extra checkouts, so I accomodate them
with some tricky dark arts behind the scenes. A full discussion of those
"dark arts" would be lengthy indeed, so let it suffice to say that I use a
few homegrown tools to manage the work of floating a few hundred files while
branching the other thousands of files in the same view. Not easy, and not
recommended, but working well here, fwiw.
For a major version 2, I would create a new project. This is only for major
fundamental restructuring type changes. If the major structure of the code
is largely the same, then I would more likely just increment the major
version number in future branches rather than create a new project.
:) dave