[p4] Codelines and Components

Bennett, Patrick Patrick.Bennett at inin.com
Thu Nov 20 11:46:31 PST 2008


Our basic model is:
//depot/{release level}/{product-line}/{'codebase'|main}/...
Release level is either user, team, systest, qa, or ga
So for systest/qa/ga:
//depot/{systest|qa|ga }/{product-line}/{'codebase' }/...
For user:
//depot/user/{userid}/{product-line}/{'codebase'}/...
For team:
//depot/team//{product-line}/{'codebase'}/{team name}...

Codebase represents a potential version release but is a bogus name with
no version affiliations.  We usually use color names like Red, Yellow,
etc.
The point is that what we call it in development has no bearing on what
marketing might end up calling it.  We might still say yeah, Red == 2.4,
but when it really gets near the point of being 'released,' we might
want to release it as something else, so we stopped putting hard
versions into our branches long ago.

'main' is also a codebase, always representing the tip or latest 'open'
codebase.  Usually ends up being a release or two ahead.

Code goes up from systest to qa, ga as it goes through the
development/testing/release cycle and hotfixes are performed against the
ga tree with fixes automatically integrating down to qa/systest and then
out along the systest branch to all 'future' codebases up through main
[always the end].

Patrick

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Matt Craighead
Sent: Thursday, November 20, 2008 1:58 PM
To: Chris Helck
Cc: perforce-user at perforce.com
Subject: Re: [p4] Codelines and Components

This is the "//depot/component/main/..." vs.
"//depot/main/component/..."
debate.

I favor the latter approach -- put all components under a shared "main".
The key advantages:

- You can use relative paths to find one component from another.
- You can modify the interfaces between components in a single atomic
commit
to the depot.
- Bug fixes and other enhancements to components are picked up
immediately,
without need to cut a new release.
- Changes don't affect other branches.  Changing //depot/releaseX will
not
affect *anything* in //depot/main.

The biggest downside is that new bugs in components are also picked up
immediately.  But discovering a bug sooner (and being forced to fix it
sooner) is usually a good thing, not a bad thing.  And if you have good
regression tests, you can prevent most breaks from happening in the
first
place using a product such as my company's Cascade, which will not only
automate your builds and regression tests, but will also refuse to allow
people to commit changes that haven't passed those build and regression
tests.


On Tue, Nov 18, 2008 at 4:27 PM, Chris Helck
<Chris.Helck at us.icap.com>wrote:

> I'm looking for tips and references on how to work with multiple
> components and codelines. We're a small Java shop and we use Maven to
> build components (jar files). We're having problems when a single
> functional change involves changes to multiple components. Issues of
> which codelines to modify, when to propagate changes, and who should
> compile against what are always popping up.
>
> For example, should an application's mainline always compile/link
> against its dependent component mainlines? Or should dependencies be
> always to release lines?
>
> Another example: if while doing a large change in a development
codeline
> I discover a small, but nasty, bug in another component. Should I
create
> a development branch for the component and fix the bug, or should I
fix
> the bug on its mainline (or even in a release line)?
>
> While we're enchanted by the promise of components we're finding it to
> be a very confusing landscape to navigate through.
>
> Regards,
> Christopher Helck
>
> **********************************************************************
> This communication and all information (including, but not limited to,
>  market prices/levels and data) contained therein (the "Information")
is
>  for informational purposes only, is confidential, may be legally
>  privileged and is the intellectual property of ICAP plc and its
affiliates
>  ("ICAP") or third parties. No confidentiality or privilege is waived
or
>  lost by any mistransmission. The Information is not, and should not
>  be construed as, an offer, bid or solicitation in relation to any
>  financial instrument or as an official confirmation of any
transaction.
>  The Information is not warranted, including, but not limited, as to
>  completeness, timeliness or accuracy and is subject to change
>  without notice. ICAP assumes no liability for use or misuse of the
>  Information. All representations and warranties are expressly
>  disclaimed. The Information does not necessarily reflect the views of
>  ICAP. Access to the Information by anyone else other than the
>  recipient is unauthorized and any disclosure, copying, distribution
or
>  any action taken or omitted to be taken in reliance on it is
prohibited.
> If
>  you receive this message in error, please immediately delete it and
all
>  copies of it from your system, destroy any hard copies of it and
>  notify the sender.
> **********************************************************************
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



-- 
Matt Craighead
Founder/CEO, Conifer Systems LLC
http://www.conifersystems.com
512-772-1834
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user





More information about the perforce-user mailing list