Re: Clearcase branching strategy

Replies: 5 - Pages: 1 - Last Post: Nov 4, 2010 9:40 PM Last Post By: ErikWaibel Threads: [ Previous | Next ]
Posts: 1
Registered: Aug 04, 2010 12:06:34 PM Clearcase branching strategy
Posted: Aug 04, 2010 12:22:50 PM Am quite new to clearcase and want to know the best branching/merging strategy to employ for a small dev team (approx 10 developers). Here's the simplest situation we encounter so I'll start with this:

Let's say we have a main branch
Off main we make a branch: A
Shortly before we release A to the public, we want to start working on the release after A.
We decide to merge A back into main and then create another branch off main: B.
We now have developers working on A & B simultaneously.
Next, we release A to the public (applause) and now want to ensure we don't loose the most recent changes to A. Should we:

Merge A into main and A into B
or
Merge A into main and then main into B
or
Merge A into B and then B into main

This is probably a fairly simple example but for when things get a bit more complicated, are there any good articles about branching strategies?

Thanks

Posts: 2
Registered: Sep 10, 2010 08:13:33 PM Re: Clearcase branching strategy
Posted: Oct 19, 2010 08:21:59 PM   in response to: KevinSheedy's post
Would you pls post it here? Thank you! Anybody can help? I've been waiting for the answer.
Posts: 195
Registered: Jan 15, 2005 05:15:03 PM
Posts: 195
Registered: Jan 15, 2005 05:15:03 PM Re: Clearcase branching strategy
Posted: Oct 20, 2010 04:09:10 AM   in response to: KevinSheedy's post I hate formatting code in forums . . . . haaaaaaaaa
.
.
.
.

People please stop thinking in Subversion. This is a ClearCase forum.

1st what you whant to achieve is typical of Subversion, and my question to you is: why you want to merge A into Main and B into Main ?

2nd ever heard of baselines? Streams?

If you merge into "main" how to you extract A and B? How do you differenciate A from B? Point in time? Excel Spreadsheets? Magic wand?

Release B is a spin off of Release A, therefore a bug fixing of A have/might merged in B.
Release C is a spin off of Release B, therefore a bug fixing of B have/might merged in C.

If you merge everything in "Main" you create a huge cahos.

In ClearCase you have this wonderful concept called Baseline. With a Baseline you can define your workspace, your starting release, bugfixing . . . Sky is the limit. Also you have streams which help you in defining your SDLC. Stop thinking in Subversion.

If you want to know more about branching strategy:
Google Brad Appletonbuy and read a wonderful book called "Software Configuration Management Strategies and Rational ClearCase"buy and read a wonderful book called "The Art of ClearCase Deployment"download the IBM Redbook called "Software Configuration Management: A ClearCase for IBM Rational ClearCase and ClearQuest"read the ClearCase manuals, they are published to let the public know about the tool
(Kevin, nothing personal)
Posts: 202
Registered: May 12, 2007 03:11:48 PM Re: Clearcase branching strategy
Posted: Nov 01, 2010 08:44:55 AM   in response to: KevinSheedy's post Hi,
you think in CVS, SVN or similar contexts..... forget those toys !!!

try someting like:
1. NEVER work on the main branch
2. think in terms of tasks (your jobs to do), and each task is always defined by:
- name of task (what to do = branch type name)
- stable baseline of task (at the end a config spec, could also be a label type in case of full labeling)
- naming convention to generate release identifiers for new releases produced within task
(releases of a task could become baselines of other tasks)
- possibly a definition of which paths to work on

Cheers,
Uwe

--
Dipl. Inform. Uwe Satthoff
( jcp@comasy.de )
currently consultant @ Airbus
( Uwe.Satthoff@airbus.com )

Posts: 3
Registered: Nov 04, 2010 09:14:12 PM Re: Clearcase branching strategy
Posted: Nov 04, 2010 09:40:38 PM   in response to: KevinSheedy's post Your best solution is to work in a 3-tier branching structure. What this allows is easy feature -> integration -> main releases and post-release changes. The following structure should help display this:

main

0

1--------int_rel1.0

2<---| 0---------------fea_change1

------1<-| 0

----------------1

This structure also allows you to work on changes that won't be released until after rel1.0 (for example).

Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular type of content or application that you're viewing.

My tags shows your tags for this particular type of content or application that you're viewing.

Use the search field to find all types of content in My developerWorks with that tag. Use the slider bar to see more or fewer tags. Popular tags shows the top tags for this particular type of content or application that you're viewing. My tags shows your tags for this particular type of content or application that you're viewing.MoreLess 

View the original article here