[p4] Codelines and Components

Chris Helck Chris.Helck at us.icap.com
Thu Nov 20 12:27:10 PST 2008


David,

We're at the point where things are breaking down. I agree that the
//depot/component/<branch> model is the way to go. Most of our
components are small (10K lines), but tightly coupled. We're finding
that small changes ripple through the dependency graph causing a lot of
confusion.

I've concluded that one of our key problems is that we're not treating
internal components as first class projects with real releases. I expect
this to be a difficult transition because all of the developers
(including me) are use to modifying the tips of any component we need to
without regard to other applications. It doesn't help that business
logic is scattered across the components.

My short term goals are to setup some simple release planning procedures
and clear guidelines.

Regards,
Christopher



-----Original Message-----
From: David Ferguson [mailto:daf at vmware.com] 
Sent: Thursday, November 20, 2008 2:52 PM
To: 'Matt Craighead'; Chris Helck
Cc: perforce-user at perforce.com
Subject: RE: [p4] Codelines and Components

My objection to the //depot/main/component is fundamentally one of
branching expectations.  That policy tends to drive people toward
branching all components every time any of them branch.  With a
//depot/component/<branch>/... Model, the likelihood that individual
components will soon have their own release schedule and branching
models is far greater. 

An individual release schedule for each component promotes cleaner
interfaces and abstraction.  When all components branch together, the
seduction of simplistic integrations is pretty successful.  Using
independent chunks of code helps isolate a component and ensure formally
defined interfaces since they never know who is going to consume them
when. 

However, my viewpoint considers each component to be a fairly large,
often separately developed, piece of major functionality.  If you're
working with a small team or lots of small tightly coupled components,
then I would agree with Matt.  Just don't stay there too long as you
grow.  At a certain point, switching to the other model can become both
technically and politically impossible.

-daf


> -----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 10:58 AM
> 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
> 

**********************************************************************
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.
**********************************************************************






More information about the perforce-user mailing list