[p4] Codelines and Components

David Ferguson daf at vmware.com
Thu Nov 20 14:07:04 PST 2008


I'm about two years after the breakdown point :(

As a build engineer it is embarrassing.  As a Perforce administrator it is too difficult.  I don't like having a 300GB database.  Keeping it well-fed and happy ain't easy...

-daf
 

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Chris Helck
> Sent: Thursday, November 20, 2008 12:27 PM
> To: perforce-user at perforce.com
> Subject: Re: [p4] Codelines and Components
> 
> 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.
> **********************************************************************
> 
> 
> 
> _______________________________________________
> 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