CODEWITHSUNDEEP
version-controlstarteam
Nix
Nix

Reputation: 58522

What should be the "trunk" development, or release

I have the unfortunate opportunity of source control via Borland's StarTeam. It unfortunately does very few things well, and one supreme weakness is its view management. I love SVN and come from an SVN mindset. Our issue is post production release we are spending countless hours merging changes into a "production support" environment.

Please do not harass me this was not my doing, I inherited it and am trying to present a better way of managing the repository. It is not an option to switch to a different SCM tool.

Current setup

My proposal is going to be to swap them, have all development be done on the trunk (Production), tag on releases, and as needed create child views to represent production support bug fixes.

I can not find any documentation to support the above proposal so I am trying to get feedback on whether or not the change is a good idea and if there is anything you would recommend doing differently.

Upvotes: 3

Views: 935

Answers (3)

Pascal Thivent
Pascal Thivent

Reputation: 570325

I use an intermediate approach inspired by Henry Kniberg's article Version Control for Multiple Agile Teams. I'm quoting a small part below:

The big picture

OK, now I've gone through a fairly detailed example of how to put this pattern to use. Now let's back out a bit and look at the big picture.

In the mainline model, a branch is called a codeline (in fact, branch is considered to be an implementation of a codeline). Sometimes these are called streams.

A codeline's parent (i.e. the codeline that it originated from) is called its baseline. Mainline is the codeline that has no baseline.

So in our examples above we could conclude that:

  • The trunk is our mainline. It has no parent right?
  • All other codelines (release 1.0, team A work, team B work) have the trunk as baseline.

Here's a more complex example:

alt text
(source: infoq.com)

This picture tells us that:

  • The project X codeline was spawned from the mainline. The project is now complete, so the branch is closed.
  • Team A has an active work branch that was spawned from the mainline.
  • Team A also has an ongoing spike that was spawned from the work branch.
  • The release 2.3 branch is closed, since 2.3 is no longer in production and won't be maintained.

Each codeline has a relative firmness level with respect to its baseline, i.e. each codeline is either more firm or less firm (softer) than its baseline.

  • A firm codeline is stable, thoroughly tested, changes seldom, and is close to release.
  • A soft codeline is unstable, barely tested, changes often, and is far from release.

When drawing codelines, firm codelines branch upwards and soft codelines branch downwards. So looking at the picture above, we can conclude that:

  • Release 2.3 is firmer than mainline.
  • Team A work is softer than mainline.
  • Team A spike is softer than team A work.

To summarize:

  • The trunk is the DONE branch (always releasable)
  • Work is done in work branches (one per team) that may be less stable than the trunk
  • Release branches are created based on the trunk at the time of the release.

I warmly recommend reading the whole article.

Upvotes: 3

Doug Porter
Doug Porter

Reputation: 7887

I agree with yours and Chris Kaminski's approach. We use StarTeam and this is how we use it. The Tip or Main view in each project is the current development line (in StarTeam terms this is the default view that has the same name as the Project name). Anytime we do builds on this view our build server creates a Build Label. A release is done as of a certain build Label.

We would then create a new View as of that Label as the production release branch and then any bug fixes to the release would be applied to that view (whether bug fixes are done in the Tip view and merged to the branch or vice versa is irrelevant, as long as they do get merged into the main Development view).

Also, if we have a particular project that is going to be long running and will not be completed prior to the next normal production release, we will do a branch off of the Tip view with the Branch on Change setting. This is definitely less than ideal since much merging must be done once it is complete, but it does keep that code out of the main development line and ensures it can't accidentally end up in a production release. We do try to limit these types of projects, but sometimes the business folks dictate them.

This setup has worked very well for us and seems to be easy for new folks to understand and work with.

Upvotes: 2

Chris K
Chris K

Reputation: 12341

Here's my general advice for structuring build streams: 

+HEAD - master -> current development 
+ tags
   + version1 
   + version1.sp1 
   + version1.sp2 
   + version2
+ branches
   + version1.sp2.fixes <- at some point, this will get promoted to version1.sp3 
   + version2.fixes <- at some point, this will get promoted to version2.sp1 
   + version2.nix.feature1 <- this is your (nix's) private version2.feature branch 
   + master.nix.feature2  <- this is your (nix's) private new development feature branch.

Basically, you NEVER commit directly to a .fixes or the master branch - only an integration process does that.

Anyhow, pretty much any source control tool will support this model.

Upvotes: 2

Related Questions