Justification in creation of branches by designers ...

[Martin]

I am posting this question to find out what is the general belief and
concensus on the level of freedom that needs to be granted to
designers for creating branches. When I look at some version trees
under clearcase, I see nothing short of a spagetti plate with
hyperlinks and merges all over the place.

The questions I have are (perhaps more or less different flavours of
the same question):

1- What kind of questions need one ask to identify if a branch created
by a designer is valid/legitimate or alternatively if it could have
been avoided?

2- What are some scenarios a desginer could abuse the concept of
branching?

2- What kind of policies/controls need one enforce to ensure branches
do not get out of hand due to mushrooming of them as designers keep
adding new branches?

Thanks.

Martin

[Stephen Baynes.]

"Martin" <mmartincm@yahoo.ca> wrote in message
news:864159ba.0306291606.331db354@posting.google.com... I am posting this question to find out what is the general belief and concensus on the level of freedom that needs to be granted to designers for creating branches. When I look at some version trees under clearcase, I see nothing short of a spagetti plate with hyperlinks and merges all over the place.

Try another tool such as Synergy which only creates branches when they are
actually needed because there are multiple descendents of a file version.
Clearcase's nature (particually if using latest on branch in reconfigure)
tends to encourage branches used to isolate work that are then merged back
in to an otherwise unchanged parent branch. Some tools use even less
branching that Synergy as they allow multiple checkouts and only allocate a
new version id when checking in, other checkouts are merged to become
checkouts of the new version - so no branching at all for simultaneous
development.
The questions I have are (perhaps more or less different flavours of the same question): 1- What kind of questions need one ask to identify if a branch created by a designer is valid/legitimate or alternatively if it could have been avoided?

Parallel or simultaneous development?
2- What are some scenarios a desginer could abuse the concept of branching?

One nasty case I came across was when then designers only have very limited
access to the test setup, perhaps only once or twice a week. So they would
prepare lots (10+!) of independent changes on separate branches. When they
got access they would run each of these as separeate tests. They did not
want a mistake in one change to affect the ability to run tests of other
changes. Once they had them working independently they would then try to
merge.
2- What kind of policies/controls need one enforce to ensure branches do not get out of hand due to mushrooming of them as designers keep adding new branches?

In Synergy - just run a show conflicts. I guess you could probably do
something with findmerge in Clearcase. For Clearcase you will need also a
clearly documented branching strategy that fits with your configuration
rules to tell the designers. One does not want to ban reasonable
simultaneous development - if you do it will just cary on but outside the CM
system.



--
Stephen Baynes CEng MBCS
DTG-S&S, Philips Semiconductors Southampton

[Eric Junkermann]

mmartincm@yahoo.ca (Martin) wrote in message The questions I have are (perhaps more or less different flavours of the same question): 1- What kind of questions need one ask to identify if a branch created by a designer is valid/legitimate or alternatively if it could have been avoided?

You could look at "Software Configuration Management Patterns:
Effective Teamwork, Practical Integration" by Steve Berczuk with Brad
Appleton (ISBN: 0201741172), and also
http://www.cmcrossroads.com/bradapp/acme/branching/ .

They have put a lot of thought into how branching should be used
without giving a single prescriptive answer. It seems to me that the
key point for you might be "Code Line Policy" - a branch should have a
clearly defined purpose.

On the other hand, you could say that anyone can create a private
branch whenever they feel like it - as long as they are personally
responsible for any resulting merges and for fitting them into their
own timescales and deadlines.

Regards,

Eric

[Jorgen Grahn]

On 29 Jun 2003 17:06:23 -0700, Martin <mmartincm@yahoo.ca> wrote: I am posting this question to find out what is the general belief and concensus on the level of freedom that needs to be granted to designers for creating branches. When I look at some version trees under clearcase, I see nothing short of a spagetti plate with hyperlinks and merges all over the place.
.... 2- What are some scenarios a desginer could abuse the concept of branching?
....

Since you mention ClearCase, the only thing i *hate* is when people create
branches, do their work, merge back, and then just leave the branches hanging
around, not marking them as obsoleted. You get the spagetti version
trees with dozens of branches, and no way of visualize which ones are still
active. "Are these pending heavy changes, which will go into mainline soon,
or are they stuff that was abandoned months ago, or are they in fact
completed?"

IME, it's rare -- even in nightmare projects -- that a single file has a lot
of active branches. Completed, dead branches are common.

/Jorgen

--
// Jorgen Grahn <jgrahn@ ''If All Men Were Brothers,
\X/ algonet.se> Would You Let One Marry Your Sister?''

[Kevin Cline]

mmartincm@yahoo.ca (Martin) wrote in message news:<864159ba.0306291606.331db354@posting.google.com>... I am posting this question to find out what is the general belief and concensus on the level of freedom that needs to be granted to designers for creating branches. When I look at some version trees under clearcase, I see nothing short of a spagetti plate with hyperlinks and merges all over the place.

Branches solve two problems:

1. Branches allow developers to check-in partially completed work.
This is preferable to having days of work stored only in a view. A
lot of shops don't backup developer views, so it's relatively easy for
work stored only in a view to be lost.

2. Branches allow developers to collaborate easily.

In short, I like branches, and will create one whenever I anticipate
doing more than about an hour's work. I name them for the work
request -- either a bug report or a feature change request.