[p4] Codelines and Components

David Ferguson daf at vmware.com
Thu Nov 20 13:46:11 PST 2008


Well, answer to the first is in client mapping if desired.
Second point is absolutely valid.  Just in practice didn't work that way very well.

-daf


________________________________
From: Matt Craighead [mailto:matt.craighead at conifersystems.com]
Sent: Thursday, November 20, 2008 1:43 PM
To: David Ferguson
Cc: Jeff A. Bowles; Chris Helck; perforce-user at perforce.com
Subject: Re: [p4] Codelines and Components

> 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<mailto: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> [mailto: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<mailto: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<mailto: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