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:Paul Cody (paul@lucidainc.com)
Date:09/13/2001 01:07:42 PM
List:com.perforce.perforce-user

It sounds as though you want to use CVS and not Perforce.

"All I want" is a tool that solves the major issues in maintaining sets of files across time that does not get in the way. Don't get me wrong, I like Perforce for:

- atomic commits (essentially why we bought it) - good branching/merging - clean workspace (state kept at server)

But you can't say that Per-force is Per-fect. IMHO, I would like to see:

- an option "free-edit|nofree-edit" that, if set, has a client thread or process that monitors the lastmod date of files in a client workspace view and sends a "p4 edit" in the background and a message to <stdout|dialog> when the modification date changes (or something like that). Possible suboption to confirm the edit. You get the best of both worlds. p4 opened would work in the same way it does now. This is would be trivially easy to implement in the P4Web and P4Win clients, and only slightly more complex with p4 command-line interface.

- ability to store comments in specification records. Each field in a record should be able to have a list of associated metadata (rendered as comments in an editor).

- easier file renaming & reorganization (like Clearcase). I haven't used Perforce long enough for this to be an issue, nor do I have a good implementation suggestion, so I should just shutup about this for now until I think of something constructive to say.

Pardon me if I seem hostile, its really nothing personal against Perforce itself or the users of this list. Been a bit angry lately. Thanks for all the feedback,

Paul

A trigger will not work. You would have to use wrappers that would check for files that differ from the database (this takes a while), and then only checks those out and then submits them. The problem is that since Perforce does not know you have files checked out, merges can be a pain since they need to be resolved before submitting. No one knows who has what checked out (we had one developer who would yell at anyone who checked out "his" files, he has since left the company), this can lead to duplication of effort.

But checking out all files is a pain. When a user syncs up, that user would need to resolve all the files checked in by other people, because Perforce won't clobber any checked out files by default, even if the user did not modify those files. Users should only check out those files they intend to modify. If you have any form of code review process, even peer review, then non-modified files would be caught at this stage.

Your users are used to working a certain way. If they cannot change, then I suggest that CVS is the tool to use.

-----Original Message----- From: perforce-user-admin at perforce.com [mailto:perforce-user-admin at perforce.com]On Behalf Of Paul Cody Sent: Thursday, September 13, 2001 2:24 PM To: 'Jeff A. Bowles'; 'perforce-user at perforce.com' Subject: RE: [p4] P4 Submit

Grrr. Is there a way to mimic CVS's way of doing things such that:

- a developer can checkout a set of files

- a developer can work on any or all of those files without having to specifically "p4 edit" each one independently

- a developer can checkin only those files that have changed.

Looks like:

p4 sync //mydepot/... p4 edit //mydepot/... p4 revert -a //mydepot/... p4 submit //mydepot/...

I can almost guarantee that our developers are going to want to "p4 edit" a bunch of files recursively such that they don't have to slow down to accomodate Perforce's totalitarian philosophy. I can also guarantee that they're gonna forget to revert -a before submitting. Can I set of a submit trigger to do this automatically?

What are the consequences of new revisions? Won't this make it difficult to quickly check a change specification... Ie I want to know "joe submitted changes to files x and z" rather than "joe submitted changes to "a b c ... x y z".

-----Original Message----- From: Jeff A. Bowles [mailto:jab at piccoloeng.com] Sent: Thursday, September 13, 2001 1:12 PM To: Paul Cody; 'perforce-user at perforce.com' Subject: Re: [p4] P4 Submit

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

I'm a new perforce user. It seems that if I "p4 edit" a set of files but never actually change any of those files, a "p4 submit" will record a change specification that indicates that those files have been edited. Am I missing something here or can Perforce not determine what files have truly been altered? CVS is smarter than this... Anyhow I hope I'm just plain wrong here.

The command "p4 revert -a" will release files that haven't been modified; "p4 submit" doesn't do that automatically, because it's doing exactly what you asked - creating a new revision of the file.

In the GUI, there's a check-box ("revert unchanged files") that you can access by right-clicking on a changelist.

Jeff Bowles Perforce Consulting Partner