Jump to content

P4Java - Lock changelist


  • Please log in to reply
3 replies to this topic

#1 eranb


    Advanced Member

  • Members
  • PipPipPip
  • 55 posts

Posted 23 March 2015 - 10:35 AM

Is there a way to lock changelist?
We use changelist as input for build system. Then we run tests and submit the code.
We want to make sure that the changelist will not change from the moment the code was pulled till we submit the code.

Any idea how can we "lock" the changelist without changeling it's owner?
We use superuser...


#2 P4Shimada


    Advanced Member

  • Members
  • PipPipPip
  • 831 posts

Posted 25 March 2015 - 01:02 AM

Hi Eran,

Yes, you can lock a changelist with the 'p4 lock' command, which locks open files against changelist submission:

p4 lock -c <changelist>


$ p4 opened
//depot/test/lock1#1 - add change 12153 (text)
//depot/test/lock2#1 - add change 12153 (text)

$ p4 lock -c 12153
//depot/test/lock1 - locking
//depot/test/lock2 - locking

$ p4 opened
//depot/test/lock1#1 - add change 12153 (text) *locked*
//depot/test/lock2#1 - add change 12153 (text) *locked*



#3 eranb


    Advanced Member

  • Members
  • PipPipPip
  • 55 posts

Posted 25 March 2015 - 08:02 AM

I think you misunderstood my question. I don't want to lock the files. I want to lock the changelist.
We want to prevent any additions to the changelist from the moment we pull the code for the build, till after submitting the changelist.

We want to prevent a case where during the tests, the developer will add another change to the changelist and the automatic flow will submit the changelist while not all changes were tested.

Currently we un-shelve the files from the original changelist to a new one and test+submit only the new changelist.
we prefer to submit the original changelist instead.


#4 P4Shimada


    Advanced Member

  • Members
  • PipPipPip
  • 831 posts

Posted 25 March 2015 - 06:34 PM

Hi Eran,

Thank you for the additional details. Sorry if I misunderstood. Let me get some further clarification for a better understanding.

Part of locking a changelist, is not being able to add any files to it - as a changelist is mostly made up of files and a description. Adding another change to a changelist could be adding or taking away a file from the change or modifying the description. Do you want?:

a] To prevent the changelist description from being modified
b] To prevent the changelist files from being modified
c] To prevent both the changelist description and files from being modified

You can restrict a changelist from public view by changing the Type: field from public to restricted. In general, if a changelist is restricted, only those users with 'list' access to at least one of the files in the changelist are permitted to see the changelist description. See Example 17. Submitting a changelist to the depot http://www.perforce....ml#files.manage
This could possibly be used to accomplish a] or b] depending on what you need to accomplish.

To accomplish a] and b] you could use the 'p4 lock -c <changelist>' command.


-- The user 'testgirl' locks changelist 12157

$ p4 opened -u testgirl
//depot/test/bar1#1 - edit change 12157 (text) by testgirl@testgirl2014.1
//depot/test/foo1#1 - edit change 12157 (text) by testgirl@testgirl2014.1
//depot/testB/bar1#1 - branch change 12157 (text) by testgirl@testgirl2014.1

$ p4 lock -c 12157
//depot/test/bar1 - locking
//depot/test/foo1 - locking
//depot/testB/bar1 - locking

-- When another user tries to open or view change 12157, which is locked
   they can only see up to the description and the files are hidden. Neither
   can users edit the changelist description as it becomes read only for all
   other users.

$ p4 -u admin change -o 12157
# A Perforce Change Specification.

Change: 12157

Date: 2015/03/25 11:26:44

Client: testgirl2014.1

User: testgirl

Status: pending

edits and branches to be shelved


-- Neither can other users submit this changelist when it is locked

$ p4 -u admin submit -c 12157
Change 12157 belongs to client testgirl2014.1.

To accomplish a], b] or c] you can use triggers. A form-out trigger which checks if the changelist form contents have changed and if so, fails with an error message. There can be a condition in the trigger script for it to succeed if it is the build user or whoever is allowed to submit it. There are examples below of how form-out triggers can be used. Also, you can use a change trigger to prevent it from being submitted under whichever conditions you prefer.


- Triggers

- Debugging Triggers

- Personalized Default Changelist Descriptions

- Enforcing Workspace Naming Conventions

- Customizing Perforce Editor Forms

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users