[p4] exclusive checkout across branches

[David Weintraub]

As Steve already pointed out, the "-l" only affects that one instance
of the file on the branch. It does anything to make the server work
harder and doesn't add anything to the protection tables. Perforce
already checks to see if a file is already open for editing by someone
else when you do a "p4 edit" on that file. And, anyone can lock a file
they're editing by simply doing a "p4 lock" on it once it is opened
for editing.

There are many arguments why file locking this isn't such a great
idea.  You can take a look at
<http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html#svn.basic.vsn-models.lock-unlock>
at the part right under the diagram, at the section beginning "The
problem with the lock-modify-unlock model" to see why forced locking
isn't such a great idea.

There are also times when doing serial changes via file locking is
important. These would include any file where you cannot do automated
merging of changes. That would include binary files (like 3rd party
compiles libraries/DLLs), icon files, and even Microsoft Word
documents. You really shouldn't have any issues if the files that the
developers want to lock are files that are either impossible to merge
or even extremely difficult to merge.

However, I'd be wary if locking becomes a fairly universal type of
activity. At that point, you're going to be spending your time
unlocking abandoned files for developers and working out disagreements
among developers who should have the right to edit a particular file.

On 1/8/07, Jamie.Echlin at barclayscapital.com
<Jamie.Echlin at barclayscapital.com> wrote:
> Sorry for all the traffic, trying to bring myself up to speed.
>
> A group has certain files that should be "exclusively lock", including
> across branches. This is particular named files, not all having a
> certain extension or anything so simple.
>
> I guess an implementation option is using +l in the typemap, and
> protections file to make read-only everywhere except the main branch. I
> don't want to do this because I'm wary of adding many rows to
> protections, also I want something whereby they can make changes to this
> list without having to be admin.
>
> I guess many people have this sort of requirement, any suggestions?
>
> My preferred option is a trigger which would read a project-supplied
> file containing list of "special access rules", ie depot path patterns
> and rules. However the trigger would only fire on submitting the
> changelist, not when they make the checkout. I prefer a trigger because
> it allows us to provide some explanation of the failure - eg please make
> these changes in this branch..., as opposed to using the permissions
> table which would just say "access denied"...
>
> Thanks in advance,
> jamie
>
> ------------------------------------------------------------------------
> For more information about Barclays Capital, please visit our web site at http://www.barcap.com.
>
> Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message.  Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed.  Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group.  Replies to this email may be monitored by the Barclays Group for operational or business reasons.
> ------------------------------------------------------------------------
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>


-- 
--
David Weintraub
qazwart at gmail.com