[p4] Implement a "p4 checkout" - Tal Dayan - com.perforce.perforce-user

10 messages in com.perforce.perforce-user[p4] Implement a "p4 checkout"

From	Sent On	Attachments
Michael Graff	05 Jan 2000 14:31
Short, Todd	05 Jan 2000 15:08
Michael Graff	05 Jan 2000 15:21
Marc S. Gibian	05 Jan 2000 15:21
Short, Todd	05 Jan 2000 15:44
Tal Dayan	16 Jan 2000 14:20
Michael Graff	17 Jan 2000 09:01
Dave Lewis	17 Jan 2000 09:15
Tal Dayan	17 Jan 2000 10:14
Chuck Karish	17 Jan 2000 10:24

Subject:	[p4] Implement a "p4 checkout"
From:	Tal Dayan (ta...@zapta.com)
Date:	01/16/2000 02:20:33 PM
List:	com.perforce.perforce-user

The lack of an atomic open/lock that fails if the file is already lock was the main complain I got when I pushed Perforce in our organization about a year ago. My understanding at that time, after communicating with a Perforce representative, was that Perforce will have it in the 'next release'.

I understand that there are excellent explanations why this is an evil and dangerous approach but nevertheless, let us set our policies and procedures, just provide us a simple tool to do it.

And on a similar note, any idea why Perforce does not have a simple 'mv' or 'rename' operation ?

TED

-----Original Message----- From: perforce-user-admin at perforce.com [mailto:perforce-user-admin at perforce.com]On Behalf Of Michael Graff Sent: Wednesday, January 05, 2000 3:22 PM To: Short, Todd Cc: perforce-user at perforce.com Subject: RE: [p4] Implement a "p4 checkout"

Yes, I understand, and we're not looking to disallow parallel work, but the folks here are not accustomed to it and want to start out with the assumption that they have the lock when they check out the file. So we'd like to have the default work the way they're used to, but if they want to p4 edit a file that somebody else has locked, that's still their choice.

Since Perforce supports parallel edits, they don't have to work around the system, and I'll make sure people understand that. I just want to give them a familiar "edit+lock or nevermind" function in addition to the separate edit and lock Perforce provides.

Once people are comfortable with the edit-resolve model, there's nothing stopping them from working that way.

"Short, Todd" <tshort at altiga.com> on 2000-01-05 15:09:21

Our folks are accustomed to serial checkouts where the first person to check out the file has a lock on it. They can't check out a file if somebody already has it locked. I'd like to make Perforce work this way by default.

Serial checkouts hurt productivity, and lead to users circumventing the system. Since multiple users cannot check out a particular file, it requires that users must wait for the file to be checked back in. I have found this type of delay unacceptable. There is no reason why 2 (or more) people should be disallowed to make unrelated changes to the same file. In order to avoid the above, users will circumvent the system by toggling the read-only attribute. This means that the SCC does not know the file is checked-out or changed, and when a user check in their files, they will likely forget the file that they circumvented, causing even more headaches such as an unbuildable system or mysterious bugs. We here have individuals who check out the same file into different workspaces, while at the same time it's checked out to other people. This allows people to add multiple features separately, or to try two different mechanisms, etc. Allowing for multiple checkouts is essential for an SCC system, and I wouldn't choose a system that didn't have it. I'm sure that Perforce has a white-paper on the subject. I just don't have the time to search for it. (Enough preaching :)