[p4] Emulate ClearCase

Sat Sep 9 02:38:46 PDT 2006

I really like this solution -  and I've been playing with the  the P4CONFIG variable to automatically determine which branch I'm working on based on the directory I'm in. And if I cant go this way now - I'm definitely going to push our team to adopt this method in the future. But the issue with this right now is that for every change we wish to test on the web-server - we need to check-in the file. This tends to get tedious - especially since GUI (css/html) related changes are always small and many. Ideally, we would be testing those minor things on our local boxes, and have the setup you mentioned for QA to have the current checked-in versions of files.

I especially like the cron job tip - I was investigating triggers for that! Cron jobs are so much easier!

-daaku

----- Original Message ---- 
From: "Weintraub, David"  
To: dlewis78731 at gmail.com; daaku6-66 at yahoo.com 
Cc: perforce-user at perforce.com 
Sent: Friday, September 8, 2006 3:06:10 AM 
Subject: RE: [p4] Emulate ClearCase 

> This is do-able, but users have to be well grounded in 
> the limitations/rules necessary to do it right. 

Perforce, in order to quickly sync a Perforce workspace/client, doesn't 
compare files (usually using a checksum or timestamp) then sync what is 
different. Instead, Perforce tracks which versions of which files you 
have  on your client and only syncs if you request a version you don't 
have. If you change the file without Perforce's knowledge, it won't sync 
the changed file. 

People at my work have run into this sort of mess until they learned 
they cannot use the same client on two different PCs. Many have both a 
laptop and a desktop, and they assumed that they could use the same 
client if they had the same root directory (C:\p4clients\default). 

If multiple users share the same client on the same machine, it starts 
getting difficult to figure out who changed what as Dave Lewis points 
out. This is completely different from ClearCase where dynamic views can 
easily be shared among different users on different machines. 

The safest method (and the one which works best with Perforce) is to use 
different working directories and different clients for different users. 
There is no problem of users having multiple Perforce clients. In fact, 
the P4CONFIG file makes it a snap. 

If I understand you correctly, the machine that everyone is suppose to 
use is your web server, and on it is the web directory that contains the 
files needed by this system. 

You need to create a new user (we'll call the "webuser") just for this 
system. Put this user in its own Perforce group. Give this group 
readonly access to the web page information stored in the Perforce depot 
and nothing else. That means no one can log into Perforce as this user 
and make a change in the depot. They have to make changes with their own 
Perforce ID. 

Now, you're going to create a Perforce client on this user, and the root 
of this client will be the root of the web directory tree. The idea is 
if you run "p4 sync" in this directory, you get the latest files in the 
depot. 

In order to make it easy for users to sync their changes in the web 
server's client, we are going to take advantage of the P4CONFIG 
environment variable. On this machine (through the Control Panel on 
Windows, or the .profile on Unix), set P4CONFIG equal to ".p4rc" or some 
other file name. Don't specify the full directory name in the P4CONFIG 
file! 

Now, create the P4CONFIG file in the root of the web directory. You are 
going to specify, P4USER as the "webuser", P4PASSWD as the password for 
the "webuser", P4CLIENT as the client for the "webuser", and P4PORT as a 
pointer to your Perforce server. That way, anyone who goes into this web 
directory tree will automatically be the special read only web user. 

Once this .p4rc file is set, run "p4 client", and it will automatically 
setup a client named in P4CLIENT. Setup the Perforce depot mapping to 
match the web directory layout. 

Now, if a user needs to update the web page, they will go into their 
Perforce client, make the changes and do a "p4 submit". Once they've 
done that, they can go to the web server machine, and run "p4 sync" in 
the web directory. If you want, you can setup a cronjob or a schedule 
task to automatically run "p4 sync" in the web directory on the web 
server every minute or so. 

-----Original Message----- 
From: perforce-user-bounces at perforce.com 
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Dave Lewis 
Sent: Thursday, September 07, 2006 11:56 AM 
To: daaku6-66 at yahoo.com 
Cc: perforce-user at perforce.com 
Subject: Re: [p4] Emulate ClearCase 

On 9/7/06, daaku6-66 at yahoo.com  wrote: 

> But basically, what I'm looking for is this: Be able to share a 
workspace between multiple users, and yet let them check-out & check-in 
files as themselves. 

This is do-able, but users have to be well grounded in the 
limitations/rules necessary to do it right. 

In our case here, we have a "build" account, but when I'm logged in as 
build I set my p4user to be "dlewis". Then whenever I check things in, 
it is done as perforce user dlewis. There are a number of kinks though. 
p4 opened lists all files open on the client, not just the ones I opened 
as user dlewis. 
I can edit any files that are open for edit on the client, but when I 
submit, only files that I opened as dlewis will be in the list of files 
to be submitted. 
Sync operations could get confusing if you want to work with anything 
other than the head revision, other users could stomp on your sync state 
and you might not know that had happened. 

The usual advice is that you shouldn't share a client between users. It 
is possible, but there will be gotcha's that will need to be anticipated 
and ironed out in some way or another. 

dave 
_______________________________________________ 
perforce-user mailing list  -  perforce-user at perforce.com 
http://maillist.perforce.com/mailman/listinfo/perforce-user 