[p4] Post pre-submit triggers... - Todd Short - com.perforce.perforce-user

8 messages in com.perforce.perforce-user[p4] Post pre-submit triggers...

From	Sent On	Attachments
Todd Short	23 Dec 2002 21:20
Paul Goffin	24 Dec 2002 01:30
Stephen Vance	24 Dec 2002 03:57
Todd Short	24 Dec 2002 06:20
Stephen Vance	24 Dec 2002 11:02
Todd Short	24 Dec 2002 12:25
Chuck Karish	24 Dec 2002 20:55
Yariv Sheizaf	24 Dec 2002 23:42

Subject:	[p4] Post pre-submit triggers...
From:	Todd Short (tsh...@cisco.com)
Date:	12/24/2002 06:20:45 AM
List:	com.perforce.perforce-user

I can certainly see people who would use this to *modify* files before submission, and I think that can be a dangerous thing. What we're looking for are checks that can only be done upon looking at the files. Personally, I'd love to use 2002.2 when it's available, but we need to go through a testing period and wait to see if there are any issues seen by us or others before we adopt it.

This is how I'd imagine post pre-submit (let's call them pre-commit?) triggers working.

First 'p4 triggers' would be updated to add the type of trigger. This would be done automatically during an upgrade:

Where <type> could be 'presubmit', 'precommit', 'clientcreate', etc. (or something like that, 'presubmit' is the current mechanism, and 'precommit' is when files are available but not committed yet to the depot). The same command options are still available.

A new '-s' option (for server) to 'p4 have' would be implemented that would only return output for 'precommit' scripts. It would lists the depot files and their corresponding local filenames. A change option (-c) would be added to the 'p4 have' command to restrict the output to the specified files in the change. The client and change would need to be specified, e.g.:

p4 -c <client> have -s -c <change> //depot/project/branch/main.c - /var/tmp/p4/main.c

A P4TEMP variable would probably be useful to indicate where to put temporary files; otherwise TMP or TEMP would be used. (May not be needed.)

The 'p4 diff' command would be enhanced to allow the diff of any file with a depot file. The -a (for any) flag could be used. e.g.:

p4 diff -a //depot/project/branch/main.c /var/tmp/p4/main.c

And that's it... ok... so where's the code so I can go off and do this? j/k :)

-----Original Message----- From: perforce-user-admin at perforce.com [mailto:perforce-user-admin at perforce.com]On Behalf Of Stephen Vance Sent: Tuesday, December 24, 2002 6:58 AM To: Paul Goffin; tshort at cisco.com; perforce-user at perforce.com Cc: support at perforce.com Subject: RE: [p4] Post pre-submit triggers...

At 09:30 AM 12/24/2002 +0000, Paul Goffin wrote:

from people who are bashing Perforce because the server is not able to allow scripts to see the new files before they are committed. These people are used to writing wrapper scripts to do CVS commits, and we are trying to avoid that since we are using Linix, Solaris and Windows.

The problem we have deals with copyright dates, whitespace, line length, etc.

The issue here is a philosophical one - the Point of Perforce is to _capture_ your engineering. You want it to enforce aspects of your development.

Though I'd also _like_ to see post-submit triggers, I can see that they are a route to "The Dark Side".

I agree that this is a philosophical issue. The other point of view is that Perforce is a Software Configuration Management tool, not just a repository and version control tool. Ensuring compliance of configuration items is a common and necessary configuration management task. We're not asking the tool to do the checking, but rather to supply the mechanism so that we can make it an integral part of the process.

I don't really understand the "Dark Side" comment. There are a number of things that have been implemented in the last few years that were originally considered contrary to the tool's philosophy, but their value has been sufficiently demonstrated to the feature planning folks.

I understand that allowing triggers to see the files in Perforce's architecture would increase the complexity on the server side because of the need to preserve storage relationships as part of the pending transaction. Perforce has stringently resisted adding complexity for what they perceive to be minimal benefit. I applaud them on that, as it has made the product the compact, fast and stable tool that it is today. I also agree that these types of checks present a valid need that the existing mechanisms don't address cleanly.

Is Perforce planning on providing post-transfer pre-submit triggers? Has anyone have a workable solution to this that doesn't involve client-side/wrapper scripts?

I use a demon. I post process all submissions (in a range) and check for things like copyright, etc. The demon sends mails to "offenders" - and it's up to them to redit and re-submit.

A demon is the recommended method. Combine that with a submission branch pattern and you have a controlled method for ensuring a clean mainline, although with some additional complexity and overhead.

Another approach would be to put all client workspaces on a network volume, which would allow the pre-submit trigger to access the file from the server. With the new multiple client root capability, cross-platform issues should be addressed, as well.

Also, one other feature I'd really want is customizable fields in the changespec a la jobspec!

I've asked for this before. Aparently it's all hard coded at the moment But I feel it'd offer big improvements.

Many of us have asked that all specs be customizable and versioned. Send your request to Support to add your name to the list.

Stephen Vance mailto:steve at vance.com http://www.vance.com/