29 messages in com.perforce.perforce-user[p4] P4 Submit
FromSent OnAttachments
Paul Cody13 Sep 2001 10:42 
Todd Short13 Sep 2001 11:09 
Paul Cody13 Sep 2001 11:11 
Jeff A. Bowles13 Sep 2001 11:11 
Paul Cody13 Sep 2001 11:23 
Arnt Gulbrandsen13 Sep 2001 11:40 
Todd Short13 Sep 2001 11:42 
Arnt Gulbrandsen13 Sep 2001 11:50 
Luke Chastain13 Sep 2001 11:54 
Simon Morton13 Sep 2001 12:01 
Bill Wishon13 Sep 2001 12:09 
Paul Cody13 Sep 2001 12:31 
Paul Cody13 Sep 2001 12:33 
Kimberly McClintock13 Sep 2001 12:39 
Paul Cody13 Sep 2001 13:07 
wiv...@us.itmasters.com13 Sep 2001 13:10 
Jeff A. Bowles13 Sep 2001 13:21 
Todd Short13 Sep 2001 13:23 
Paul Cody13 Sep 2001 13:43 
Stephen Vance13 Sep 2001 21:25 
Arnt Gulbrandsen14 Sep 2001 05:17 
Steve Bennett14 Sep 2001 07:41 
Jack Tan14 Sep 2001 10:43 
Dave Foglesong14 Sep 2001 16:24 
Steven Bennett17 Sep 2001 07:12 
Stephen Vance17 Sep 2001 07:38 
Steve Bennett17 Sep 2001 07:57 
wiv...@us.itmasters.com17 Sep 2001 08:50 
Chuck Karish18 Sep 2001 07:55 
Subject:[p4] P4 Submit
From:Stephen Vance (ste@vance.com)
Date:09/13/2001 09:25:11 PM
List:com.perforce.perforce-user

Wow! I lose touch with e-mail for a day, and a full-scale flame war erupts!

I must say, Paul, that your concept of a technically correct but transparent to use CM system is intriguing. Although it's not a reason to stop wishing for it or pursuing it, I am not aware of any mainstream CM system that takes this approach, although there are ways to accomplish something like it with most.

I'll put in my two cents worth only with some comments that haven't been brought up yet.

First, and I mean this informatively not condemningly, is that although this may be your group's typical usage pattern, it is not the typical usage pattern of most organizations I have seen that have adopted a serious CM system, as you have. Most organizations that adopt a CM system are trying to come up with a more precise control of the access to their code through all stages of the process. Some would perceive the approach you want to take as chaos up to the point of submission. This may account for some of the rancor in the thread.

The other comments are more pragmatic than pedantic.

I would not recommend checking out large blocks of files. The next paragraph will give you an alternative. Here's why. Everyone checks out lots of files, whole trees worth. A) Your have lists and therefore have database will be huge. Now consider the first person to check in files. The chance that someone else has that file checked out, possibly for no good reason, is near 100%. Therefore, everyone else will have to either perform a resolve on their next sync or revert and sync. You've now taken the absolutely most common operation (syncing) and made it more difficult so you can make the second (editing) or third (submitting) most common operations purportedly easier.

Now for a proposal. Set all of your clients "allwrite." There was just a post that asked about automatic client modification, although the clientspec idea is better. Create a wrapper script that implements Tech Note #2 in a manner that is reasonably intelligent and friendly for adds (e.g. ignores some files like object files and prompts the user on the rest with the default as "add all"). You also have the rename issue that Tech Note #2 doesn't solve well, but that's probably not the normal case.

Another proposal that may or may not work for you. If you are on Windows and your environment allows, have your developers operate typically in P4Win. Drag and drop check out and double-click viewing and editing are pretty simple and precise, and the Revert Unchanged is very accessible. If Unix, try tkp4 (a new version was just announced). Rick has put a lot of effort into making it as usable or more so than P4Win. If Visual Studio or CodeWarrior, use the SCC or P4CW integrations. Automatic checkout on edit with most user commands easily accessible is quite powerful.

Steve

At 11:11 AM 9/13/2001 -0700, Paul Cody wrote:

Perhaps, but this seems like an exceptional case. I would wish for typical usage patterns to be the default rather than vice-versa.