[p4] Codelines and Components

Matt Craighead matt.craighead at conifersystems.com
Thu Nov 20 13:43:28 PST 2008


> However, just because you've set up the directories so that they can be
released independently doesn't mean that
> you must do that.  You can still branch each and every one of them as a
single unit and treat them that way if you
> want, you're just not obligated to.

The trouble is then with relative paths.  If //depot/x/main and
//depot/y/main are both branched to //depot/x/rel and //depot/y/rel, you
have to update every single "../../y/main" relative path to "../../y/rel",
instead of just using "../y" everywhere and having it work in any branch.
Or you have to set an environment variable for which branch you are in,
which is error-prone.

On the other hand, //depot/main/x and //depot/main/y does not prevent you
from branching just a single component.  You can branch as much or as little
of the tree as you want, subject to the interdependencies between the
components (e.g. you must branch any header file your component depends on).



On Thu, Nov 20, 2008 at 3:30 PM, David Ferguson <daf at vmware.com> wrote:

>  So very true...  I'm just fighting a massive inertia where everybody
> wants to go toward unit-testing the components and enforcing the
> compatibility requirements, but nobody is willing to actually identify the
> interfaces themselves because the components were treated as a single ball
> of mud so long that they're massively incestuous.
>
> However, just because you've set up the directories so that they can be
> released independently doesn't mean that you must do that.  You can still
> branch each and every one of them as a single unit and treat them that way
> if you want, you're just not obligated to.  If, sometime in the future, you
> can start splitting off pieces and treating them independently, this format
> gives you a head-start on that without significantly onerous overhead, I
> believe.
>
> But, maybe I'm just too frustrated with the past couple of weeks and have
> lost my objectivity...
>
> -daf
>
>
>  ------------------------------
> *From:* jeff.a.bowles at gmail.com [mailto:jeff.a.bowles at gmail.com] *On
> Behalf Of *Jeff A. Bowles
> *Sent:* Thursday, November 20, 2008 1:22 PM
> *To:* David Ferguson
> *Cc:* Matt Craighead; Chris Helck; perforce-user at perforce.com
> *Subject:* Re: [p4] Codelines and Components
>
>   Sure.  The only hitch is, you live or die based on the quality of the
> unit-tests of each component.
>
> If you are in a company with a strong culture of very formal API interfaces
> between components, strict unit-testing of each method in those components,
> and some sort of "I'm the wrong version of the component to load with
> version 2.1 of this other component" support at run-time...
>
> .... then it works well. Really well. Practically wonderfully.
>
> Only you know if you have that sort of culture.
>
> (If you don't, however, then the "separate component" models develop very
> nicely until they (often) fall apart when deployed to the QA group or,
> worse, in the customer's hands.)
>
>   -Jeff Bowles
>
>
>
> On Thu, Nov 20, 2008 at 11:52 AM, David Ferguson <daf at vmware.com> wrote:
>
>> 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.
>>
>


-- 
Matt Craighead
Founder/CEO, Conifer Systems LLC
http://www.conifersystems.com
512-772-1834



More information about the perforce-user mailing list