[p4] Client confusion

Mark Hersey mhersey at foliage.com
Wed Oct 5 16:55:50 PDT 2005


We address this issue by a convention that a client specification in
parenthesis (which usefully sorts to the top of the list) should be used as
a template for all developers on a specific product codeline.

Then if something changes in the template we simply send out an email to all
concerned telling them to "Create/Replace Client using (xxxx) as Template"

The cool thing is that developers can do this typically without worrying
about first checking in existing changelists.

A second benefit is that we use the (template client specs) as the
definition to be used by our automated build system - so changing the master
client spec also is set to cause a server build of affected products -
checking that the change has been made centrally correctly.

Mark Hersey
Engineering Director
Foliage Software Systems


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com]On Behalf Of Jonathan Arnold
Sent: Wednesday, October 05, 2005 12:16 PM
To: J. Paul Reed
Cc: 'perforce-user at perforce.com'
Subject: Re: [p4] Client confusion


J. Paul Reed wrote:
> Jonathan Arnold wrote:
>
>> I'm sure this has come up before, but it would be nice if there
>> was some way to have system wide clients, where everyone shares
>> the same view, only it is relative to themselves. Or maybe some
>> way to have a templated client, that automagically picks up changes
>> from everyone else.
>
>
> The obvious question that pops to mind is why are shared clients being
> used at all?
>
> We use shared clients so people have access to tools and such, but the
> client specs are locked to everyone save build engineers and the client
> areas are exported via read-only NFS.

I don't really understand; maybe there is some new nomenclature I'm not
familiar with, but I'm not sure what you mean by "shared clients".  What
I mean by that is there are 4 developers working on a project.  They each
have their own client, with their own view.  But actually, the views are
the same, except that the destination is different. So I might have:

  //depot/Main/project1/...  /jarnold.project1/...
  //depot/Main/libs/...  /jarnold.project1/libs/...

and another developer might have

  //depot/Main/project1/...  /cgolis.project1/...
  //depot/Main/libs/...  /cgolis.project1/libs/...

The problem that comes up is if I add another path to my view because I'm
pulling in more common code:

  //depot/Main/common/... /jarnold.project1/common/...

And if I forget to tell everyone, their build breaks. Or even if I do tell
everyone, they all need to go in and make the change. A real pain, albeit
something that doesn't happen too often.

> You can use a spec depot to version client specs, and then do a standard
> filelog to see when the specs changed and how they changed.

Cool. Didn't know about the spec depot.  I'll look into it.

--
Jonathan Arnold               (mailto:jdarnold at buddydog.org)
Jiggle The Handle, a personal blog    http://jiggle.anaze.us

Procrastination is the art of keeping up with yesterday.
  - Don Marquis
_______________________________________________
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