[p4] "p4 lock" is too awkward and unsafe for proper "atomic m erges" - Jeremy Russell - com.perforce.perforce-user

4 messages in com.perforce.perforce-user[p4] "p4 lock" is too awkward and uns...

From	Sent On	Attachments
Piaw Na	18 Apr 2000 09:36
Jeremy Russell	18 Apr 2000 10:13
Gil Tayar	18 Apr 2000 10:28
Paul Mitchell	18 Apr 2000 12:52

Subject:	[p4] "p4 lock" is too awkward and unsafe for proper "atomic m erges"
From:	Jeremy Russell (jrus...@channelpoint.com)
Date:	04/18/2000 10:13:23 AM
List:	com.perforce.perforce-user

I have developed a web based locking mechanism using Perl CGI. It is very much in the beta mode but here is the basics of our setup:

* Each Tree has an owner. The tree owner information is stored in a database. * There can be multiple owners. * Each owner has the ability to lock and unlock trees for specific users, groups (if we used them), or all users. * The owner can only change protections for the tree they own. * Each entry can be indefinite or each entry can have an expiration time. (I have a cron job that removes the entry after it expires). * This locking and unlocking site supports 150+ trees across multiple depots and servers. With proper training of the Tree owners, out protections table has not gotten out of hand.

All this is to say that you use the limitations of the protections table to your benefit as long as there is policing occurring by the sys admins. This gives a lot of power to Tree owners for locking entire trees for a limited amount of time, giving individual users access to a tree while keeping everyone else out, and keeps the Tree owners from bugging the sys admin to be constantly updating user groups. It has worked well for us and Perforce has asked that when we get it to an acceptable level of reliability, to publish it. They have seen it and like it.

It is not hard to create tools such as this and address deficiencies in the product.

-----Original Message----- From: Dave Foglesong [mailto:dfogleso at adobe.com] Sent: Tuesday, April 18, 2000 10:52 AM To: Chris Newcombe; perforce-user at perforce.com Cc: Chris Newcombe Subject: Re: [p4] "p4 lock" is too awkward and unsafe for proper "atomic merges"

In the past, when I've needed to lock an entire tree, I've used the protect mechanism to exclude write access to most users. This will require intervention by your P4 admin, but if you set up the protections using groups, then the admin just has to edit the group's members to allow or disallow specific users from being able to modify files.

This may not work for your model (if you're doing several of these operations every day the admin would be constantly updating the group), but it is another option you could consider.

Dave F>

----- Original Message ----- From: Chris <mailto:chris at hyperbole.com> Newcombe To: perforce-user at perforce.com <mailto:perforce-user at perforce.com> Cc: Chris <mailto:chris at hyperbole.com> Newcombe Sent: Tuesday, April 18, 2000 9:07 AM Subject: [p4] "p4 lock" is too awkward and unsafe for proper "atomic merges"

Hi everyone,

Below is a copy of an email that I recently sent to support at perforce.com <mailto:support at perforce.com> . It describes an awkward, annoying problem with 'p4 lock'. This is *not* the old "I want to lock and edit" (anti-merge) argument. This is about the lack of support for doing safe "atomic merges" to high-integrity codelines. I have described my problem, and then the obvious (very simple) solution.

I'm still talking to the support team about this, but the early response has been "[we] understand your need, and will log your request, but such a locking scheme is unlikely to be implemented because it is contrary to Perforce's philosophy of being unobtrusive". I strongly disagree. It seems to me that this feature is in fact *required*, to provide the safeguards necessary to allow developers to work properly in parallel.

Is anybody else interested in lobbying for this feature to be added to Perforce?

Thanks for your time,

Chris Newcombe Senior Producer, Hyperbole Studios

---------------------

Hi, <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> I've hit an awkward problem (or a problem of awkwardness...)

We plan to have a high-integrity code mainline, and then parallel private development branches, one per user, for people to use as sandboxes. (I want engineers to be able to submit incomplete or broken changes if they like, without disturbing the mainline.) Each user's client view will see the mainline and that user's devline, obviously.

To preserve the quality of the mainline, I need to enforce the following safe-merge scheme. (This is very close to what I've done with wrapper scripts and PVCS in the past)

1. Submit final tested changes to devline 2. Lock the mainline so no-one else can change it 3. Sync the latest revisions from the locked mainline into the client 4. Integrate from mainline to development branch, using branchspec 5. Resolve mainline->devline conflicts. Use p4 resolve -am (automatically accept non-confliciting changes) then p4 resolve (use 'e' and 'a' to resolve conflicts) 6. Build, test and debug the new devline 7. Submit new devline 8. Integrate new devline back into mainline using (reverse) branchspec. 9. Resolve the apparent conflicts (but there aren't any really). Use p4 resolve -at (accept all devline versions) 10. Submit new mainline 11. Unlock mainline

The problem is that p4 lock will only operate on files that are already opened in a changelist. I need to be able to lock the whole mainline to prevent other users from changing it at all during the merge process.

I want to do this:

p4 lock //client/main/... p4 sync //client/main/... ... p4 integrate -b branchspec (main->dev) p4 resolve -am (accept non-conflicting merges) p4 resolve (use 'e' and 'a' to resolve conflicts) ...build, test, debug.... p4 submit (new devline) ... p4 integrate -r -b branchspec (dev->main) p4 resolve -at (simply use devline versions) p4 submit (new mainline) ... p4 unlock //client/main/...

But instead it seems that I have to involve a whole fake change list, just to get p4 lock to process the files I want. This is slower, annoying and error-prone, and it also forces me to do the sync before the lock, so there is a danger (however small) that another user may submit changes after the sync and before the lock.

p4 change (create 'fake' changelist nnn for p4 lock)

p4 sync //client/main/... (must do the sync before the lock now - slightly dangerous)

p4 edit -c nnn //client/main/... (prepare files so that p4 lock will work on them) p4 lock -c nnn ... p4 integrate -b branchspec (main->dev) p4 resolve -am (accept non-conflicing merges) p4 resolve (use 'e' and 'a' to resolve conflicts) ...build, test, debug.... p4 submit (new devline) ... p4 integrate -r -b branchspec (dev->main : reopen all changed mainline files in the default changelist) p4 resolve -at (simply accept devline versins) p4 submit (new mainline) .... p4 unlock -c nnn p4 revert -c nnn (prepare to throw away fake 'lock' changelist) p4 change -d -c nnn (throw away fake 'lock' changelist)

So:

1. Can I somehow force the sync (to head revisions) on open files, so I can put the sync after the lock, where it belongs? (p4 sync -f says "is opened and not being changed".) However, I am only having this problem because p4 lock requires that the files be open. So...

2. Is there any current way to avoid generating a changelist just to lock the mainline?

3. If not, would you consider adding a new p4 filelock command (or whatever) that locks arbitrary files in the depot? (Restricted to those in the client view of course)

Many thanks for your help,