Hi Dan,
could you expand on you item 4 , I am one of those
developer who 'loves' to see branches back on main when tested and
co-worker
reviewed very much from there it officially becomes available
to all.
We do not have to support multiple platforms and already release
versions are supported
'SUPPORT MAIN Branches' based on a lazy branching principle.
I would be very interested in why seems against the back to main idea.
Sorry if is misinterpreted what you are saying
regards
Danny T
Dan Rickhoff wrote:
>
> Carl,
>
> I found the Rational web site that I mentioned, i.e., the one with the
> RUC 2000 presentations:
>
> Navigate to:
>
> http://www.rational.com/support/presentations.jsp
>
> Click on "RUC '00 Conference Proceedings and Presentation"
>
> Work your way through the required logins to:
>
> http://www.rational.com/support/presentations/ruc.jsp?
>
> Click on
> Rational User Conference 2000
> Login is required
>
> and supply the username, ruc2000, and password "victory".
>
> Click on the icon labeled "ccm" with the picture of a running man.
>
> Download the handout from the presentation:
>
> CCM02 - Rational ClearCase Branching and Labeling Best Practices
> for
> Parallel Development, Brad Appleton.
>
> Regards,
> Dan
>
> ----------
> From: Dan Rickhoff <dan.rickhoff@home.com>
> Date: Tue, 24 Jul 2001 15:47:18 -0700
> To: Carl McMullen <cwm@windchill.com>, <cciug@rational.com>
> Subject: Re: [cciug] Branching Strategy Question
>
> Carl,
>
> Brad Appleton gave an excellent presentation on branching
> strategies at last year's (Aug., 2000) Rational Users
> Conference. I can't find it right now, but it used to be
> available, somewhere or other, at Rational's web site. You
> could probably pressure your Rational Sales rep to help you
> get a copy.
>
> A few of my own opinions on a some things you mentioned:
>
> 1) Yes, "working on main" is a *BAD* idea. That is, it's
> highly unlikely that "working on main" is the most efficient
> way to use ClearCase for product development. Consider an
> analogous organizational statement that is easier to accept:
> It's highly unlikely that putting all files (every single
> one) in the same directory is not the most efficient way to
> organize and use a filesystem for product development.
>
> 2) Aside from the automatic creation of a /main/0 version
> whenever an element is created, forget about branch "main".
> You can create a branch for any purpose; there's nothing
> special about "main" to cause you to use it. On the other
> hand, there is something special about main that is a reason
> not to use it: there is only 1 "main" branch.
>
> 3) Until everything else in your process model and its
> implementation is humming along perfectly, forget about
> removing any no-longer-needed versions, minimizing branch
> creations, removing no-longer-needed branches, or minimizing
> the number of view creations. That is really, really,
> low-priority stuff, and runs against the grain of
> configuration management. First things first.
>
> 4) Developers with previous ClearCase experience often are
> very emphatic that code must be merged back to the "main"
> branch. Pound into their skulls, repeatedly, that a valid
> goal at your company is to make money for the companies
> investors by selling a product, and that "merging back to
> main" is not actually a valid goal, or even a required
> sub-goal along the way.
>
> 5) When it comes to deciding if a ClearCase branch is
> appropriate, the absolute #1 thing to think of is the
> "activity *isolation*" that the branch *will* provide. That
> isolation will both drive the need for a branch and be an
> argument against using a branch. It's not a win-win
> situation; it's an uncomfortable compromise; nothing is
> perfect.
>
> 6) Identify and define "atomic", "molecular", "granular",
> etc. development activities and interdependent sets of
> sibling activities. Where by "sibling" I mean that the
> activities are at the same level in the hierarchy of all
> activities, big and small. If 2 or more sibling activities
> are so interdependent that they *must* have access to
> each-other's checked-in changes during development, and
> further, if the interdependency is such that they *must* be
> "delivered" in concert to their parent activity, then
> development of those activities should be performed on the
> same branch. If both those criteria are not met then don't
> use the same branch for those sibling activities.
>
> 7) ClearCase provides 2 heavy-duty, powerful, large-scale
> organizational mechanisms: branches and components (VOBs).
> Read Brian White's book. Try to formulate and understand
> criteria for identifying "components". To use both
> mechanisms to best advantage, you must understand what each
> provides that the other doesn't. To organize a particular
> set of stuff, don't use branches when components would work
> better, and visa versa.
>
> Thanks for your well-written posting,
> Dan
>
> From: "Carl McMullen" <cwm@windchill.com>
> Date: Tue, 24 Jul 2001 15:41:17 -0500
> To: cmtalk@accurev.com, cciug@rational.com
> Subject: [cciug] Branching Strategy Question
>
> All:
>
> In the last couple of months, the Integration team
> that I work in has had numerous discussions with
> Development about branching strategy. We use the
> Rational ClearCase product.
>
> We proposed a somewhat traditional strategy
> involving development branches that were created
> from the /main branch. Development countered with
> a "simpler" approach where they simply do all
> development right on /main. The only time branches
> are created from /main is near the end of the
> release when some post release work needs to be
> started that can't be on /main yet. After the
> release, then the work from these branches would
> get merged back to /main and the branched removed
> ...
>
> In the last week or so, I've begun to realize some
> of the problems with this approach.
>
> * The /main branch will get loaded up with
> versions, most of which should not be kept
> long term.
> * If developers instead worked on a dev branch,
> off of /main, then at the end of each
> release, the released version would get
> merged back to /main and then the dev branch
> and all of it's versions could get removed.
> Then after the merge back to /main, the post
> release bug fix branches could be created
> from the merge-back version on /main, as well
> as the development branches for the next
> release.
>
>
> Part of the problem in this organization is that
> the Integration team has no VETO power over
> Development with regard to Configuration
> Management. One of the things that Development
> avoids thus far, at all costs, is merging! I
> believe this may be the primary reason for their
> wanting to work from /main.
>
> Another "reality" of this organization is that we
> do builds right on the development branch. So to
> "control" what goes into a build, we do label
> management instead of controlling what is merged
> to the branch.
>
> I left Development and joined the Integration team
> in the last year, so I am still quite new to some
> of these Configuration Management issues. I would
> like to hear from any of you that agree that this
> "working on /main" is a bad idea with more reasons
> why this is a bad approach.
>
> Thanks in advance!
>
> Carl McMullen. - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - [ To unsubscribe, send
> email to
>
> using the sign-up form at
> the ClearCase
> http://clearcase.rational.com/cciug/mailing_list.html
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 22:04:04 EDT