20 messages in com.perforce.perforce-user[p4] Seeking Perforce tuning tips
FromSent OnAttachments
Jeff Bowles15 Oct 2003 14:33 
Matt...@DSTInnovis.com15 Oct 2003 14:58 
Bennett, Patrick15 Oct 2003 15:31 
Eric D. Blom15 Oct 2003 15:51 
Matt...@DSTInnovis.com16 Oct 2003 11:03 
Noel Yap16 Oct 2003 11:45 
Ivey, William16 Oct 2003 13:12 
Jeff Bowles16 Oct 2003 15:40 
Chuck Karish17 Oct 2003 07:52 
Matt...@DSTInnovis.com17 Oct 2003 10:24 
Noel Yap17 Oct 2003 10:28 
Kevin Wang11 Nov 2003 17:42 
Stephen Vance11 Nov 2003 18:25 
jab11 Nov 2003 19:50 
Chuck Karish11 Nov 2003 21:47 
Robert Cowham12 Nov 2003 01:25 
Kevin Wang13 Nov 2003 10:21 
Robert Cowham13 Nov 2003 13:13 
Kevin Wang14 Nov 2003 09:35 
Chuck Karish15 Nov 2003 13:28 
Subject:[p4] Seeking Perforce tuning tips
From:Robert Cowham (rob@vaccaperna.co.uk)
Date:11/13/2003 01:13:33 PM
List:com.perforce.perforce-user

-----Original Message----- From: Stephen Vance [mailto:steve at vance.com]

There were three good papers on performance at the last two user conferences. You can find them online at the Perforce site.

Maybe I'm being blind. all I can find is the perforce manual page on performance tuning. Help?

http://www.perforce.com/perforce/conf2003/index.html

The papers are linked. Check out 2001 conference as well.

From Robert Cowham Just to pick up on this bit of Steve's advice - why are you using -I? In most cases it isn't necessary.

actually, in our case, it most definitely is. We've tried -i and other options and they just don't work right. -I works the "most right" of any of the combinations we've tried. We really do need it. -i just won't do the right things for us.

I'd need more detailed branching history to be able to advise more on this, but the paper I referenced showed some tricks as to how to set up a "standard" branching relationship between previously unrelated codelines.

With one branch per development project from the mainline, are you just propagating changes back and forwards between mainline and each project branch?

Not all project branches are directly off the trunk. some branches are also in the "wrong" place, so until they finish, we have to keep supporting them with -I. the alternative is to rebranch them from trunk and integrate-I them to be up-to-date. but that's particularly expensive. Our only real trouble is that some folks accidentally type integrate -I //depot/trunk/... //depot/project/... and unless we notice and kill it, that's a 2 hour (minimum) integration, blocking out all users! Plus the several days of cleaning up the disaster it leaves behind.

Note that you can edit the protections table to remove the ability to branch files for some (groups of) people.

However, do you mean that these people should be allowed to branch, just not with the "-I" flag?

One way of spotting what commands are being executed is to run your server with some debugging info, and then have a process sit tailing the server log and spotting duff commands:

C:\Perforce>set P4DEBUG=server=1 C:\Perforce>p4d -r C:\perforce -p 1666 -L p4d.log Perforce Server starting... Terminate batch job (Y/N)? y

C:\Perforce>tail p4d.log Perforce server info: 2003/11/13 21:03:40 pid 24716 completed 0s mapstate(0) Perforce server info: 2003/11/13 21:07:46 pid 25196 server starting Perforce server info: 2003/11/13 21:07:55 pid 25024 bruno at bruno_ws 127.0.0.1 'user-integ jam.c newjam.c' Perforce server info: 2003/11/13 21:08:00 pid 25676 bruno at bruno_ws 127.0.0.1 'user-revert ...' Perforce server info: 2003/11/13 21:08:02 pid 24976 bruno at bruno_ws 127.0.0.1 'user-integ -I jam.c newjam.c'

The script could then zap the offending users from afar, or take other appropriate action. For an example of this kind of thing, I know that Brad Barber has some Perl scripts in his area in that tail the journal and execute lots of useful commands. Might be a good starting point.

HTH Robert