[p4] Who deleted a client

Russell C. Jackson rcjackson at alum.atu.edu
Wed Oct 3 09:18:49 PDT 2001

The way we handle this situation is to do the following:

1. Create the clientspec
2. Run p4 client -o > clientname.txt
3. Check in clientname.txt into the source area for the product it belongs
4. Modify the build script to first sync out clientname.txt
5. Then the build script runs p4 client -i < clientname.txt
6. Then it does a full sync against that client to setup for the build.

Now anytime anyone wants to modify the client, they just checkout
clientname.txt, modify it, and check it back in. That gives us a revision
history on the file, a trail of who modified it, and the ability to easily
recover it if someone deletes it.

It works great.


Russell C. Jackson
rcjackson at alum.atu.edu

-----Original Message-----
From: perforce-user-admin at perforce.com
[mailto:perforce-user-admin at perforce.com]On Behalf Of Chris Patti
Sent: Wednesday, October 03, 2001 8:33 AM
To: perforce-user at perforce.com
Subject: RE: [p4] Who deleted a client

At 08:37 AM 10/3/2001 +0100, you wrote:
>Well this has come up before and I believe hasn't yet been done for
>performance reasons, and because you can do it yourself.... One tends to
>need to draw a line somewhere, and so far this is where it has been drawn.
>That said, things could change - make sure that support knows you want it -
>the more people requesting features the more likely they are to be looked

That makes sense, and I know I'm not (and I hope noone else is either)
critizing the design decisions that were made in the past - it sounds like
a reasonable trade off for the time.

However Perforce is being used today in environments where, say, having the
clientspec of a very critical build area altered at the last minute causing
the build to fall on its face and delay shipment by another oh-so-crucial
time to market day is a catastrophic event.

Ditto for protections.  Some sort of audit trail is necessary.

Also you're right in that you can do it yourself in both cases, but when
you do it this way you demand a certain level of cooperation from the user
- the problem being that in many environments the users can't always be
counted upon to remember to cooperate, so subtle but important changes slip
in, things get out of sync and we're back to square one.

We're trying here at ATG to artificially create some of this, and we're
finding the interfaces available to be somewhat more awkward than perhaps
they ideally could be.

(BTW - Just for some perspective - these are all nits.  Perforce is a
stellar product that we're all extremely pleased with.)

perforce-user mailing list  -  perforce-user at perforce.com

More information about the perforce-user mailing list