[p4] Exclusive locking binary files

G Barthelemy gb.perforce at googlemail.com
Sat Feb 9 00:31:08 PST 2008


I haven't come across this particular issue, but I can think of a
solution I had some success with recently and which could help with
making sure that the clients will open for edit files that are on the
#head revision on particular branches.

There is this recent p4broker server application (available on the ftp
site under r07.3). For that I think you need a 2007.3 server though
(and clients at least on 2007.2). The p4broker allows you to pass or
reject commands made by clients to the server, based on criteria of
your choice. Some scripting is required.

I think that the p4broker was originally designed to fake the response
from the server to the client, by rejecting commands and by outputting
the reply from another Perforce query in the REJECT message. For
example if a user issues "p4 changes" you could filter and reject that
and output the result of "p4 changes -u joeblogs" in the reject
message on STDOUT. But that will only work for command line clients
(because GUI clients and some scripts require a tagged format). Plain
text is redirected to information window / console, so although the
user would see the output in P4Win / P4V, it would be in the wrong
place...

The broker is placed between your server and clients (and proxies if
any). You could have the broker listening on 1666 and talking to your
Perforce server on 1666 if they are on different IPs. Not all clients
or proxies have to use it, maybe just the group that's on that
particular project. Personally I use a broker to filter access to the
metadata (changes, jobs, fixes, etc...) on our production server, for
a particular group of users and for a particular depot path, in
conjunction with protection table rules. In this particular case, it
was a preferable solution to a remote depot based solution.

In your case, you could have a filter rule for "edit" that would
invoke a script that interrogates your Perforce server to check that
the files passed as argument to the edit command and matching a
pattern for your branches have the #head revision equal to the #have
revision for that particular client. IIRC you can even filter based on
the client version string, so you could apply this just to P4Win
clients.  If all is OK, then you just issue a "PASS" on STDOUT. If
not, you issue a "REJECT" with a string explaining the reason and
asking the user to sync first. This message will appear in an
information window and on the console window in P4Win.

It's all a bit of a faff, but that should work quite well.

Guillaume

On Feb 7, 2008 10:56 PM, Craig James <Craig.James at thq.com> wrote:
> Hi everyone,
>
>
>
> I'm hitting a problem with locking that comes at a different angle to
> the issue described in this thread
> http://maillist.perforce.com/pipermail/perforce-user/2007-September/0224
> 30.html.
>
>
>
> We are using 2007.2 and the basic problem is...
>
>
>
> 1.       Both users sync and keep P4Win open
>
> 2.       User 1 checks out a binary file using P4Win, changes and checks
> it in
>
> 3.       User 2 now checks out the same file using P4Win (without F5
> refreshing perforce win client), changes file and goes to check it in -
> but finds the file has been changed and cannot merge their own changes
> in
>
>
>
> This is quite a problem for us as it doesn't enforce a sequential user
> workflow on binary files (such as bitmap/photoshop images or 3d models).
> Falling back on resolving differences at check-in is just not an option.
>
>
>
> If User 2 refreshes P4Win before checking out (with F5), perforce will
> ask the user if they wish to edit current or sync before edit.  Relying
> on users to do this is problematic.
>
>
>
> There are two pieces of design here that do not suit what we are looking
> for:
>
>
>
> 1.       P4Win doesn't refresh the file status before open-for-edit.
>
> 2.       There is no server-side feature to prevent clients from
> opening-for-edit a binary file at an earlier revision.
>
>
>
> The first is a problem for us if we only work through P4Win and the
> second is a problem also for any p4 command line open-for-edits.
>
>
>
> Ideally we'd be looking for either/or/both:
>
> 1.       Option in P4Win to force refresh of file status before
> opening-for-edit.  I'd gather there is a performance reason this is
> there but that is a trade off we'd be prepared to manage in the wider
> case
>
> 2.       A server-side flag that prevents a file from being opened at an
> earlier revision - something like the check for the exclusive open flag.
> This would actually solve it for both the P4Win client and the command
> line but would seem to be a more significant change.
>
>
>
> If there was a trigger on open-for-edit we might be able to work around
> this ourselves but from the thread above, this appears to not be
> available - is this correct?
>
>
>
> The only option I can see atm is to force each client to refresh every
> minute (when inactive) but this is still open to holes where the above
> can still happen.
>
>
>
> I'm keen to hear whether anyone else has come across this issue and
> resolved it some other way?
>
>
>
> Thanks,
>
> Cj
>
>
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



More information about the perforce-user mailing list