Perforce trigger to deny submission of unchanged files?

Question

Perforce allows people to check in unchanged files. Why any version control system would allow this is beyond me, but that's a topic for another question. I want to create a trigger that will deny the submission of unchanged files. However, I have no experience with Perforce triggers. From what I've read, I'm guessing this would be a "Change-content" trigger since the files being submitted would have to be diffed against the respective head revisions they are about to replace. I would need to iterate over the incoming files and make sure they had all indeed changed. The problem is, I have no idea how to go about it.

Can anyone with Perforce trigger experience offer an example or at least point me in the right direction?

Answer 1

In recent version of perforce allow a client setting which prevents submitting unchanged files:

    SubmitOptions:  Flags to change submit behaviour.

            submitunchanged           All open files are submitted
            submitunchanged+reopen    (default).

            revertunchanged           Files that have content or type
            revertunchanged+reopen    changes are submitted. Unchanged
                                      files are reverted.

            leaveunchanged            Files that have content or type
            leaveunchanged+reopen     changes are submitted. Unchanged
                                      files are moved to the default
                                      changelist.

                          +reopen     appended to the submit option flag
                                      will cause submitted files to be
                                      reopened on the default changelist.

This might be an avenue to investigate if the user is just checking unchanged files due to apathy.

EDIT:

Given that you want to enforce the restriction regardless of the user's workspace settings, then you'll need a trigger as suggested in other answers.

You'll need to look at Perforce's documentation to work out the details, but you'll need a change-content trigger.

You'll probably want to pass in %user% as well as %change% plus possibly other variables, so that you can restrict the expensive operations to just the problem user.

Answer 2

If you look at the Triggers table in Perforce, you will see that triggers are nothing but scripts that get invoked when some kind of event happens. In your case, the change-content event is triggered.

You have several options to write scripts that interact with Perforce. The Perforce downloads page has libraries and modules for many widely use languages. Any of this will help you and greatly simplify what you need to do. Also, check the Perforce Documentation page and download the administrator's guide. It will explain how to create the trigger, etc.

Basically, you need to write a script that will get the information from the change list that is being submitted and for each file in it run a "diff" command against the server. If you find a file that has not change, you need to invalidate the submission.

The Perforce module on you favorite language and the administrators guide will give you all the answers you need.

Answer 3

You'll want to write a change-content trigger. These triggers are run after files are transferred to the server, but before they are committed to the DB. As per the perforce documentation, you can use a command similar to the following

p4 diff //depot/path/...@=<change>

In the change-content trigger the @= (where change is the changelist number sent to the trigger) will get you the contents of the files that were submitted. If you are looking for a way to check against the server version, you might be able to do something like

p4 diff -sr //...@=<change>

The -sr command will report on files that open and are the same as the current depot contents. Since the files haven't been committed yet, I'm going to assume that you will actually get a list of files whose contents that have been transferred to the server are the same as the current head revision in the depot. If p4 diff -sr returns any files that are the same, return a non-zero exit code and the submit will be halted and the user will have to revert his unchanged files manually.

I don't think that you want to actually modify the contents of the changelist by doing the revert for him. That sounds too dangerous.

Note that you can write your trigger in any language that makes sense (as a previous poster suggested). I do think that this kind of trigger is going to be pretty heavyweight though. You will essentially be enforcing a diff on all contents submitted for all users in order to make one developer step in line. Maybe that's an okay price to pay, but depending on the number of users and the sizes of their changelist (and files), this kind of trigger might take a long time to run.