ClearCase Branching using configspec

The problem is:

What directories actually have:

a version in the branch BR_PHASE2 ?a version labeled LBL_MS_PHASE2_04-NOV-2010 ?

If you only branch/labeled all files under /myVob/myDirectory, then the directory /myVob itself won't never be branched/labeled.

That means the following config spec won't be able to select any version for /myVob, making all the other rules for any file under /myVob useless:
Until ClearCase is able to select at leat one valid version of /myVob, it won't be able to select any version for any file under /myVob.

element * CHECKEDOUT element * /main/BR_PHASE2/LATEST

You should always end your config spec with a "config stop-rule" like:

element * /main/LATEST

or at least:

element /myVob /main/LATEST

Add one of those at the end of your config spec, and the view should work as expected.

The ClearCase config spec mechanism is a composition-based one: to know more about it, see the SO answer "Flexible vs static branching (GIT vs Clearcase/Accurev)".

The OP adds:

You have mentioned to always end the cs with: element * /main/LATEST,

Not necessarily:

If you want to be sure to only view the files under /myVob/myDir with the right branch/label, you could use as I mentioned above:

element /myVob /main/LATEST

The rule applies only to /myVob (not to anything under /myVob).
That allows ClearCase to get past /myVob (because it can at least select a valid version for it) and start applying the other selection rules to the sub-directories.

but if I want to check out the files only from the branch BR_PHASE2, wont this create an error. I am saying that when I end it with /main/LATEST and checkout and check in files , it is updated in main branch. what do I do about it ?

It depends on the config spec you are using:

element * CHECKEDOUTelement * /main/BR_PHASE2/LATESTelement * /main/LATEST

would indeed create new version in the main branch

element * CHECKEDOUTelement * .../BR_PHASE2/LATESTelement * /main/LBL_MS_PHASE2_04-NOV-2010 -mkbranch BR_PHASE2 element * /main/LATEST

would not, because the third rule would apply first, if the element has been labeled LBL_MS_PHASE2_04-NOV-2010.

View the original article here

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

Re: Clearcase branching strategy

Replies: 4 - Pages: 1 - Last Post: Nov 1, 2010 8:44 AM Last Post By: Uwe Satthoff 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: 1
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: 201
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 )

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