[p4] Way to implement strict exclusive-open protocol? - Paul Mitchell - com.perforce.perforce-user

19 messages in com.perforce.perforce-user[p4] Way to implement strict exclusiv...

From	Sent On	Attachments
Paul Du Bois	22 Feb 2001 12:03
Karl Elvis MacRae	22 Feb 2001 15:26
Schaible, Joerg	23 Feb 2001 02:05
Chris Patti	23 Feb 2001 10:08
Paul Mitchell	23 Feb 2001 12:02
Matthew Rice	23 Feb 2001 13:40
Chris Patti	23 Feb 2001 13:43
Dave Foglesong	23 Feb 2001 14:24
Richard Geiger	23 Feb 2001 14:31
Chris Patti	23 Feb 2001 14:42
Richard Brooksby	23 Feb 2001 15:40
Robert Cowham	24 Feb 2001 06:23
John Belmonte	25 Feb 2001 02:04
Jeff A. Bowles	25 Feb 2001 07:50
John Belmonte	25 Feb 2001 19:41
Tony Smith	26 Feb 2001 02:30
Tal Dayan	21 Oct 2001 18:13
Jonathan Biggar	21 Oct 2001 19:22
Tal Dayan	21 Oct 2001 19:45

Subject:	[p4] Way to implement strict exclusive-open protocol?
From:	Paul Mitchell (pmit...@ati.com)
Date:	02/23/2001 12:02:05 PM
List:	com.perforce.perforce-user

I just want to weigh in that we too find the lack of a way to implement strict-locking a problem as well. I would imagine that almost anyone who uses Perforce to manage binary files would agree. In addition, I think the suggestion that this could be implemented via a new file type called 'lock' which could be combined with other file types is an excellent, probably straightforward to implement, transparent to users who don't want it, way of implementing this feature.

-----Original Message----- From: Schaible, Joerg [mailto:Joerg.Schaible at gft.com] Sent: Friday, February 23, 2001 5:06 AM To: 'perforce-user at perforce.com' Cc: support at perforce.com Subject: RE: [p4] Way to implement strict exclusive-open protocol?

Hi,

there have been a lot of discussion on this topic on the list. Basically Perforce functionality is not sufficient for this kind of behavior. Perforce has to be enhanced by their development to support strickt locking. The best suggestion, I've read to get a strict locking, was by using a new file type 'lock', that could be combined with the existing file types like the 'execute' type.

Perforce's paradigm is parallel development without strict locking, that I prefer too. But I cannot understand that Perforce is rejecting their customer's wishes at this topic for several years now. If a company would like to use another locking paradigm and if the Perforce technology could support it that easily, WHY WON'T THEY SUPPORT IT? Even I would like to use strict locking for some binary files. I bet, Perforce would gain a lot more customers, who won't change their used locking scheme, but search alternatives for products like MKS Source Integrity, PVCS or Source Safe. Giving them a smooth possibility to switch, they may discover the adnvantages of a non-strict locking scheme at their own - when they are used to the new tool and learnd to trust it.

Greetings, Jorg

GFT Technologies AG, Germany

-----Original Message----- From: Karl Elvis MacRae [mailto:kmac at pico.apple.com] Sent: Friday, February 23, 2001 12:27 AM To: Paul Du Bois Cc: 'perforce-user at perforce.com' Subject: Re: [p4] Way to implement strict exclusive-open protocol?

This is something that *really* should be enhanced by perforce. They need to add a strict lock - that will stop p4 open/edit as wel as stopping p4 submit. This is the same issue my team are trying to address, and there really isn't a clean solution.

-Karl

On Thu, Feb 22, 2001 at 12:03:38PM -0800, Paul Du Bois spake thus:

For binary files in our depot that can't be merged, I'd like to keep more than one person from opening the file at a time. The problem is that it is too easy for users to overlook the "XXX also has this file open" messages.

Note that p4 lock is not a sufficient solution -- it doesn't prevent other users from wasting time editing the file before they try to submit and find that it's locked.

This needs to work for the GUI as well as the command line, otherwise I'd just write a wrapper. Anyone have clever ideas? The only thing I can think of is messing with protection lines all the time, which I think would be more trouble than the problem is worth.