Stumbling Toward 'Awesomeness'

A Technical Art Blog

Saturday, September 25, 2010

Perforce Triggers in Python (Pt 2)

So last time I more introduced you to the idea of triggers, here’s a more complex example. This worked on my db, but if you have branching you would need to check each returned file against the branch you are submitting to.

Check if The File is Already in the Depot

This is a trigger that checks the hash digest of the incoming file against that of the server. This way you can see if the user is checking in a file that already exists.

import sys
from P4 import P4, P4Exception
p4 = P4()
describe = []
	p4.user = "admin"
	p4.password = "admin"
	p4.port = "1666"
	lst = sys.argv[2]
	stat ='fstat', ('-Ol','//depot/...@'+ str(lst)))
	hash = stat[0]['digest']
	fname = stat[0]['depotFile']
	m ='fstat', ('-Ol','-F', ('digest = ' + str(hash)),'//depot/...'))
	existing = []
	for file in m:
		if file['depotFile'] != fname: existing.append(file)
	if existing != []:
		print '\n\nFILE EXISTS IN DEPOT!!'
		print  'YOUR FILE:  ' + (fname.split('/')[-1])
		for  file in existing: print 'EXACTLY MATCHES:  ' + file['depotFile']
		print 'P4 DIGEST:  ' + hash
		print 'SOLUTION: Contact your lead if you believe this message was generated in error.'
except Exception, e:
	print "Error: %s" % (e)

Then your trigger line looks like this:

	dupeCheck change-submit //depot/... "python X:/projects/2010/p4/ %user% %changelist%"

This is what the user will see when they try to check in:

posted by admin at 7:39 PM  


  1. Ignoring the obvious performance problem (retrieving EVERY file’s hash every time you submit?! — test this with 1k, 10k, 100k, 1M files in your depot and see how long the trigger takes to run), this trigger totally breaks down if you do any branching (and possibly any renaming), for when you submit branched file(s), it’ll complain about a branched file being the same as an existing file (its parent). I highly recommend you avoid implementing this trigger in any production environment.
    Good luck!

    Comment by xqnstyl — 2010/09/27 @ 7:59 AM

  2. I was under the impression that fstat queried the perforce database or table a single time for files matching your submission’s digest.

    The reason I was writing this was because after a lot of googling I find nothing online similar. The examples on the p4 site are simple to a point of not being useful.

    Would you help set others straight who are searching for a way to do this like i was and find nothing on the internets?

    Comment by admin — 2010/09/27 @ 11:37 PM

  3. Sounds easily solvable with a cache if that is the problem…

    Comment by Oskar H — 2010/09/28 @ 9:14 AM

  4. xqnstyl,

    We just had a perforce guy here, onsite at my company. He said, re: the trigger above, the only way to do this better is to mirror your p4 database to a MSQL database that has hash digest as a key. Then with every change to the p4 db you have a trigger that updates the mirrored SQL db. Then when your checkin trigger checks the hash against the SQL database, and not the p4 database.

    Seems like a lot of hoops to jump through.

    Comment by admin — 2010/11/14 @ 11:32 AM

RSS feed for comments on this post. TrackBack URI

Leave a comment

Powered by WordPress