20 messages in com.perforce.perforce-userUPDATE: [p4] Perforce running dog slow| From | Sent On | Attachments |
|---|---|---|
| Sweeney, Nicole | 14 Sep 2001 14:51 | |
| Matthew Rice | 14 Sep 2001 15:39 | |
| Kate Ebneter | 14 Sep 2001 17:41 | |
| Jeff A. Bowles | 14 Sep 2001 18:20 | |
| Nick Barnes | 17 Sep 2001 05:32 | |
| Jeff A. Bowles | 17 Sep 2001 07:08 | |
| Nick Barnes | 17 Sep 2001 09:22 | |
| Sweeney, Nicole | 18 Sep 2001 11:14 | |
| Chuck Karish | 19 Sep 2001 07:18 | |
| Michael Peck | 19 Sep 2001 07:58 | |
| Sweeney, Nicole | 20 Sep 2001 13:39 | |
| Dave Lewis | 20 Sep 2001 14:02 | |
| Chuck Karish | 20 Sep 2001 21:08 | |
| Robert Cowham | 20 Sep 2001 23:20 | |
| Dave Lewis | 21 Sep 2001 11:49 | |
| John D. Mitchell | 21 Sep 2001 13:46 | |
| Kumar | 21 Sep 2001 14:13 | |
| Brian Moyers | 21 Sep 2001 14:47 | |
| Karl Philipp | 24 Sep 2001 00:58 | |
| Tyler, Tom | 24 Sep 2001 11:52 |
| Subject: | UPDATE: [p4] Perforce running dog slow |
|---|---|
| From: | Sweeney, Nicole (nico...@akamai.com) |
| Date: | 09/20/2001 01:39:24 PM |
| List: | com.perforce.perforce-user |
Thanks for your input, Chuck. I must not have been as clear as I could have been...
I don't see what you gain by doing this. You could accomplish the same thing by setting up clients that map the whole depot and never changing them, putting the effort to determine which files to check out into your sync commands.
We are working on changing our build process now to accomodate the tool. This still does not help individual users or admins deleting clients.
For the most part this only happens when a machine is reassigned or when a user leaves the company. It doesn't have to scale.
I guess that this depends on your usage model. Our usage model is project based. This means that each weekly release consists of one or more project branches. We have many different products in parallel, and releasing on different schedules. One developer may be working on any number of projects at a time. To keep these workspaces separate, the user creates a client specification per project. We have 375 users doing this at one time on many different products, projects, and release schedules. When release goes out, the project is terminated, and the client spec is no longer needed. The natural thing to do is delete it. This approach seemed like the cleanest way for our complex environment.
You are correct that for many usage models, smaller implementations, and less complex enviroments, it does not have to scale. BTW - There is an excellent paper on branching strategies by Brad Appleton. It can be found at: http://www.enteract.com/~bradapp/acme/branching/
I must have missed the description of this issue. What's the problem?
Commands like "p4 files" and "p4 changes" that are issued to operate on large sets of files take many minutes to complete. The real issue is that no other commands can complete during this time. This causes Perforce to appear to "hang" during this time... The biggest culprit is "p4 files //...foo..." and "p4 files @label". I understand that the workaround for these issues is to limit the number of files they operate on, i.e. "p4 files //depot/main/...foo...". Users will still inadvertantly do the former, even after being educated on the effects.
Nicole
-----Original Message----- From: Chuck Karish [mailto:karish at well.com] Sent: Wednesday, September 19, 2001 7:19 AM To: Sweeney, Nicole; 'perforce-user at perforce.com' Subject: RE: UPDATE: [p4] Perforce running dog slow
At 11:14 AM 9/18/2001 -0700, Sweeney, Nicole wrote:
Our build process creates a temporary client based on only what is needed, syncs and runs the build, and then deletes the client when finished. Each build is very different and is run on any one of our 12 build slaves based on availability. The temporary client thing seemed the best way to go process-wise because it helped us to keep our client specs as small as possible, old clients weren't left around, and we didn't need to worry about what was building or where.
I don't see what you gain by doing this. You could accomplish the same thing by setting up clients that map the whole depot and never changing them, putting the effort to determine which files to check out into your sync commands.
Knowing what we know now about the tool we are modifying our process a bit to deal with the scaling issues, but the real issue is still there. Even if our build process stops deleting clients, our users and myself will still need to delete clients. It just doesn't scale.
For the most part this only happens when a machine is reassigned or when a user leaves the company. It doesn't have to scale.
Even if this issue goes away, we are still left with the p4 files issue, which seems to worsen over time as our depot grows.
I must have missed the description of this issue. What's the problem?
Chuck Karish karish at well.com (415) 317-0182