[p4] Client confusion
streak at narus.com
Wed Oct 5 19:28:20 PDT 2005
Jonathan Arnold wrote:
> J. Paul Reed wrote:
> 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/...
I assume you're sure there will never be a //depot/Main/project1/libs
That's the problem I've always had with client paths that include other
> 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.
One thing that strikes me about the above is the way the client
structure is being changed based upon the branch structure. I've found
things work out a lot easier if the client structure matches the branch
structure. It prevents a lot of tweaks to clientspecs to get things
In the above, why not use something like:
If the build from that client work, it'll also simplify branching and
Just my $.02.
More information about the perforce-user