[p4] Codelines and Components

Matt Janulewicz matt.janulewicz at lucasfilm.com
Thu Nov 20 17:56:03 PST 2008


In P4V it can figure out the right hand side when you drag and drop into 
the View window, or use the graphical editor. It's probably a function 
of P4V, though, and not p4.

I agree with remaps in client specs. If you have to remap it usually 
points to a good opportunity to refactor your code. If your remappings 
are sufficiently complex and your workspace includes a huge tree of code 
you can add some significant compute times to P4 functions, too.

As I found out yesterday, if you put odd mappings in there just right 
you might even crash your server.


-Matt


Matt Craighead wrote:
> 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
>>
>>
>>     
>
>
>   



More information about the perforce-user mailing list