[p4] Codelines and Components

Matt Craighead matt.craighead at conifersystems.com
Thu Nov 20 13:52:34 PST 2008


Every Perforce project I've worked on has had a convention that using
clientspecs to remap directories was prohibited -- too error-prone and
confusing.

Wish you could fill in only the left-hand-side of a clientspec if the
mapping was 1:1.  Never understood why it can't figure out the RHS
automatically in this common case... you can't even tell users to just
copy-and-paste in a "standard" clientspec without first telling them to do a
search-and-replace with their clientspec name.  Again, all very error-prone.

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

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


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



More information about the perforce-user mailing list