[p4] Re: Perforce Configurations

Paul Andrei pandrei at foliage.com
Sat Mar 19 16:09:40 PST 2005

Chuck Karish wrote:
> On Fri, 18 Mar 2005 09:20:22 -0500, Paul Andrei <pandrei at foliage.com> wrote:
>>In order to completely specify a file/component version in Perforce, one
>>has to provide its space-time coordinates: the depot path is the
>>location (space coordinate) while the revision/change/label is the time
> You seem to have fallen prey to the CM fallacy: the notion that source
> control can be implemented by simply selecting the appropriate
> versions of different files or components from the ongoing stream
> of changes.

But that's the ideal, isn't it? And it's a very appropriate way of 
including third party libraries into a product's monolithic source tree: 
no one's gonna bug-fix the third party tools, isn't it.

> For the most part the real world doesn't work that way.  The idea of
> making a link to a label breaks down when the release represented
> by the label needs a bug fix and the fix isn't appropriate at the head.

The real world isn't very far from where we live :-). We do create 
branches when this happens, like everyone else.

And if server-side (Perforce depot) symbolic links were employed, we 
would've changed them to point to the new branch.

> The fix has to be added to the label as references to branched
> versions of the modified files (or to a version of each of these
> files that is itself a server-side symbolic link).

You are not very clear here, I'm afraid.

> If the first option is
> chosen all client specs on the main branch and/or branch specs
> for other branches have to be adjusted.

If server-side symbolic links were available, the clientspecs would 
usually be very simple, one-to-one straight mapping most of the time. 
And they wouldn't need to change so often because they would not have 
any role in the configuration management. Plus they would be very easy 
to setup by all team members (foolproof).

> Eitther way, the result will
> come to resemble a mass of pasta that has been allowed to sit for
> too long after draining.

We all hate that, don't we? :-)

>>It takes discipline and
>>effort from everyone to stay up-to-date. A solution built into Perforce
>>is preferable.
> Your tools aren't good enough (which is not to say that ours are.)
> If the tools are sufficiently complete that developers can rely on them
> as their primary interface to the souce control facilities they extend
> (generating proper client specs) it won't take an extraordinary effort for
> developers to get the code they need.

The effort is not extraordinary: it's just not foolproof.

That's actually a very good topic: what tools/scripts are people using 
on top of Perforce clients (P4, P4API, etc)? And what for?


More information about the perforce-user mailing list