[p4] Client-Side Submit Triggers

[Rajul Vora]

I am pretty sure this doesn't exist yet in perforce. But I was wondering if
such a thing did exist and it was supported from p4 and p4win, it would be
one way to implement some of the submit time (pre or post) processing that
can only happen on the client.

For example, to integrate perforce into my defect tracking system I could
implement a client-side submit trigger to launch a GUI that allows the user
to associate the changelist with a defect. I can't lanuch a GUI (or do any
user interaction) with server-side triggers.

In fact, that's how Rational integrates clearcase with clearquest, if I am
not mistaken. I am not sure if this is the best way to do the integration in
all cases, but sure sounds like a good idea.

#

[Chuck Karish]

What functionality do you want that you can't get with a
wrapper for p4.exe or by writing a tool using the p4 API?



--
Chuck Karish BEA Systems
***@bea.com San Francisco, CA
[phone] (cell) [phone]

[Jeff A. Bowles]

At 3:16 PM -0700 4/14/00, Chuck Karish wrote:
>What functionality do you want that you can't get with a
>wrapper for p4.exe or by writing a tool using the p4 API?

Ultimately, a client-side trigger can be used to verify
certain things are in the workspace or that the workspace
version of the files do "something" correctly.

For example, a client-side trigger that says "check for an
object file that has a date newer than the file getting
checked in" is a *very* basic "did it compile?" test. Not
a very good one, mind you, but still it's better than
nothing. (This is something a server-side trigger cannot do.)

Or a trigger that checks for a unit-test log file that's
newer than the source file being checked in, the implication
being that the developer ran the tests before running "p4 submit".

Heck, a client-side trigger might even run the compile itself
or rerun regressions. There are lots of choices.

The reason a hack to "p4.exe" (or a wrapper) or using the P4 API
isn't sufficient do these sort of things is that you want to ensure that
this 'trigger' behavior is run every time, not just when the
developer runs "the right client executable/program" to do
the submit. That is, by the way, one reason that client-side
triggers aren't there at the moment, I suspect: how can you
CLEANLY guarantee that the client-side trigger is ALWAYS run
on the platforms it's supposed to, and that it has access to
the right tools to do its job? (For example, do you want to
assume that check-ins from a platform that lacks a C compiler
are good? Are never good? There be dragons there....)

Please don't take this as an argument FOR client-side triggers
or AGAINST 'em. It's neither, and both. It's an argument against
assuming that it's a simple problem.

And to anyone who says "but ClearCase has 'em" (and it does),
I'd respond: yes, but getting *consistent* and *helpful* behavior
from 'em is no fun.

-Jeff Bowles
Perforce Consulting Partner (and trainer and all sorts of things)

[Frank Merrow]

At 11:28 AM 4/17/00, you wrote:
>At 3:16 PM -0700 4/14/00, Chuck Karish wrote:
>>What functionality do you want that you can't get with a
>>wrapper for p4.exe or by writing a tool using the p4 API?

Actually, I can name you another one, in fact several:

As P4 Admin:

On check in, check to see if the file contains $Header:$ or $Id:$ and
refuse to allow the check in if "Keywords" aren't enabled in the File_Type.

This is a common developer problem I'd like to fix with a client side
trigger of some kind. As it stands now, the best I can to is to ask the
Depot for the PREVIOUS version and see if the keyword is there. However,
I'm sure you understand why I consider this less than optimal.

As P4 Developer:

As a developer, I'd really like to add to triggers to scan my code for
certain problems. Is the Qualcomm Copyright present? If so, has it been
updated to the current year. Are current coding standards proper for the
current file?

These vary from group to group within the company so a Depot wide trigger
isn't a good solution. However, as a developer I can think of lots of
reasons to Quality Check my code and prevent check in if certain things
haven't been done.

One thing you'll notice with BOTH examples . . . the problems they are
trying to solve could still be done with server side triggers if the
UPDATED FILES were available on the server when the trigger was running,
but before they were actually checked into the archive. The fact that the
files are not available to the triggers is a repeatedly inconvenient
problem IMHO.

However, even if you did to a TEMP copy of the new files and make that
available to the triggers (a great idea all by itself), as a developer, I'd
still like to have client side triggers than I can control. No P4 Admin
worth his salt is going to allow 15 developers to be mucking about on the
company's depot all the time to tinker with their personal triggers. You
need a trigger that the USER can install and manage, but that the Admin
doesn't have to fret about all the time.

Frank

[Frank Merrow]

At 04:24 AM 4/18/00, Arnt Gulbrandsen wrote:
>Frank Merrow <***@qualcomm.com>
> > However, as a developer I can think of lots of
> > reasons to Quality Check my code and prevent check in if certain things
> > haven't been done.
>
>As another developer, I can think of lots of reasons to do that too.
>
>But I wouldn't tie it to checkin. Quality control is part of what you
>do while you work with a piece of code, not something you do as you
>hand in the finished job.

Absolutely agreed . . . it should have already been done.

However, it is nice to check it one last time as it walks in the Depot door
. . . just for that "rare case" (like 70% of the time) where the programmer
"forgot".

I speak now not as Perforce Admin or Joe Developer, but rather as Team Lead.

(Now where did I put that other hat?)

Frank

[Arnt Gulbrandsen]

Frank Merrow <***@qualcomm.com>
> However, as a developer I can think of lots of
> reasons to Quality Check my code and prevent check in if certain things
> haven't been done.

As another developer, I can think of lots of reasons to do that too.

But I wouldn't tie it to checkin. Quality control is part of what you
do while you work with a piece of code, not something you do as you
hand in the finished job.

--Arnt

[Rob Jellinghaus]

From: Jeff A. Bowles [mailto:***@pobox.com]
>At 3:16 PM -0700 4/14/00, Chuck Karish wrote:
>>What functionality do you want that you can't get with a
>>wrapper for p4.exe or by writing a tool using the p4 API?
...
>For example, a client-side trigger that says "check for an
>object file that has a date newer than the file getting
>checked in" is a *very* basic "did it compile?" test. Not
>a very good one, mind you, but still it's better than
>nothing. (This is something a server-side trigger cannot do.)
...
>The reason a hack to "p4.exe" (or a wrapper) or using the P4 API
>isn't sufficient do these sort of things is that you want to ensure that
>this 'trigger' behavior is run every time, not just when the
>developer runs "the right client executable/program" to do
>the submit. That is, by the way, one reason that client-side
>triggers aren't there at the moment, I suspect: how can you
>CLEANLY guarantee that the client-side trigger is ALWAYS run
>on the platforms it's supposed to, and that it has access to
>the right tools to do its job? (For example, do you want to
>assume that check-ins from a platform that lacks a C compiler
>are good? Are never good? There be dragons there....)

I think you've just summarized the reason why Perforce shouldn't
even really *try* to implement client-side triggers.

Getting the p4 command itself to be portable is hard enough. I
can see little or no way Perforce could integrate client-side
extensible scripting (which is sort of what you're asking for)
into the portable p4 command. Consider all the variants: do you
want to run a DOS batch file? a Unix shell script? a Perl script?
Are you on Windows? BeOS? Macintosh? What are the exit code
conventions? Can every type of script even return the right sorts
of exit codes? There's far too much local variation here.

What prevents you from setting up your clients' environments such
that the raw p4 tool is completely inaccessible? You're *always*
in a situation where the developer needs to run "the right client/
executable program" to do the submit. The big issue is whether
you provide two ways to do it--the right way, via myp4wrapper or
whatever, and the wrong way, via raw p4--or whether you only
provide one way, namely myp4wrapper, and contrive to hide the raw
p4 command altogether. Again, the details of how you would do this
are specific to your OS, your procedures, and your preferred
support tools, which all argues against Perforce trying to solve
this particular worm can.

>And to anyone who says "but ClearCase has 'em" (and it does),
>I'd respond: yes, but getting *consistent* and *helpful* behavior
>from 'em is no fun.

I suspect that the reasons why this is so are the same reasons why
it would be equally hard to get good behavior from Perforce client-
side triggers, were Perforce to implement them.

You said you weren't arguing particularly for or against client-side
triggers; from my perspective, you were arguing quite effectively
against :-)

Cheers,
Rob

[Scott Blachowicz]

Rob Jellinghaus <***@quokka.com> wrote:

> What prevents you from setting up your clients' environments such
> that the raw p4 tool is completely inaccessible?

What about environments where some people use the p4win GUI? As far as I know
there's no way to hook the GUI aside from writing your own GUI from scratch
as I know other(s) are doing. And even then, you would need to make sure that
everyone uses the same wrapped tool (or provide for multiple wrapped
tools)...

I can see some utility to client-side scripts, but also probably
enough PITA factor in doing them to make life a little difficult.

Scott

[Rajul Vora]

Ditto.

I love the CLI, but Perforce has already added a GUI client and now a p4web
client is in the works so the wrapping the CLI won't cut it if you want a
consistent behaviour across an enterprise with heterogeneous clients.

As for the "portability" concerns, the server side triggers (pre) already
have those concerns and therefore perforce has spelled out the limitations.
You can't access the files that you are submitting, etc.

I am not asking perforce to make sure I don't fall in the holes I dig but as
long as I can deal with my own creations, I don't see why perforce should
say "I know better, thou shalt not run client-side triggers". I think they
argued a long time about not doing server side pre-submit trigger for the
same reasons of portability, etc. But in the end, having an option with
reasonable limitations is better than not having it at all.

Rajul

> -----Original Message-----
> From: Jeff A. Bowles [mailto:***@pobox.com]
> Sent: Monday, April 17, 2000 11:29 AM
> To: Chuck Karish
> Cc: Rajul Vora; perforce-***@perforce.com
> Subject: Re: [p4] Client-Side Submit Triggers
>
>
> At 3:16 PM -0700 4/14/00, Chuck Karish wrote:
> >What functionality do you want that you can't get with a
> >wrapper for p4.exe or by writing a tool using the p4 API?
>
> Ultimately, a client-side trigger can be used to verify
> certain things are in the workspace or that the workspace
> version of the files do "something" correctly.
>
> For example, a client-side trigger that says "check for an
> object file that has a date newer than the file getting
> checked in" is a *very* basic "did it compile?" test. Not
> a very good one, mind you, but still it's better than
> nothing. (This is something a server-side trigger cannot do.)
>
> Or a trigger that checks for a unit-test log file that's
> newer than the source file being checked in, the implication
> being that the developer ran the tests before running "p4 submit".
>
> Heck, a client-side trigger might even run the compile itself
> or rerun regressions. There are lots of choices.
>
> The reason a hack to "p4.exe" (or a wrapper) or using the P4 API
> isn't sufficient do these sort of things is that you want to
> ensure that
> this 'trigger' behavior is run every time, not just when the
> developer runs "the right client executable/program" to do
> the submit. That is, by the way, one reason that client-side
> triggers aren't there at the moment, I suspect: how can you
> CLEANLY guarantee that the client-side trigger is ALWAYS run
> on the platforms it's supposed to, and that it has access to
> the right tools to do its job? (For example, do you want to
> assume that check-ins from a platform that lacks a C compiler
> are good? Are never good? There be dragons there....)
>
> Please don't take this as an argument FOR client-side triggers
> or AGAINST 'em. It's neither, and both. It's an argument against
> assuming that it's a simple problem.
>
> And to anyone who says "but ClearCase has 'em" (and it does),
> I'd respond: yes, but getting *consistent* and *helpful* behavior
> from 'em is no fun.
>
> -Jeff Bowles
> Perforce Consulting Partner (and trainer and all sorts
> of things)
>
> _______________________________________________
> perforce-user mailing list - perforce-***@perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>

[Rob Jellinghaus]

I just thought of one counter-argument to my own post, here: p4win doesn't
currently support any extensibility, and I don't think it supports invokin g


-----Original Message-----
From: Rob Jellinghaus [mailto:***@quokka.com]
Sent: Monday, April 17, 2000 11:56 AM
To: 'Jeff A. Bowles'; Chuck Karish
Cc: Rajul Vora; perforce-***@perforce.com
Subject: RE: [p4] Client-Side Submit Triggers


From: Jeff A. Bowles [mailto:***@pobox.com]
>At 3:16 PM -0700 4/14/00, Chuck Karish wrote:
>>What functionality do you want that you can't get with a
>>wrapper for p4.exe or by writing a tool using the p4 API?
...
>For example, a client-side trigger that says "check for an
>object file that has a date newer than the file getting
>checked in" is a *very* basic "did it compile?" test. Not
>a very good one, mind you, but still it's better than
>nothing. (This is something a server-side trigger cannot do.)
...
>The reason a hack to "p4.exe" (or a wrapper) or using the P4 API
>isn't sufficient do these sort of things is that you want to ensure that
>this 'trigger' behavior is run every time, not just when the
>developer runs "the right client executable/program" to do
>the submit. That is, by the way, one reason that client-side
>triggers aren't there at the moment, I suspect: how can you
>CLEANLY guarantee that the client-side trigger is ALWAYS run
>on the platforms it's supposed to, and that it has access to
>the right tools to do its job? (For example, do you want to
>assume that check-ins from a platform that lacks a C compiler
>are good? Are never good? There be dragons there....)

I think you've just summarized the reason why Perforce shouldn't
even really *try* to implement client-side triggers.

Getting the p4 command itself to be portable is hard enough. I
can see little or no way Perforce could integrate client-side
extensible scripting (which is sort of what you're asking for)
into the portable p4 command. Consider all the variants: do you
want to run a DOS batch file? a Unix shell script? a Perl script?
Are you on Windows? BeOS? Macintosh? What are the exit code
conventions? Can every type of script even return the right sorts
of exit codes? There's far too much local variation here.

What prevents you from setting up your clients' environments such
that the raw p4 tool is completely inaccessible? You're *always*
in a situation where the developer needs to run "the right client/
executable program" to do the submit. The big issue is whether
you provide two ways to do it--the right way, via myp4wrapper or
whatever, and the wrong way, via raw p4--or whether you only
provide one way, namely myp4wrapper, and contrive to hide the raw
p4 command altogether. Again, the details of how you would do this
are specific to your OS, your procedures, and your preferred
support tools, which all argues against Perforce trying to solve
this particular worm can.

>And to anyone who says "but ClearCase has 'em" (and it does),
>I'd respond: yes, but getting *consistent* and *helpful* behavior
>from 'em is no fun.

I suspect that the reasons why this is so are the same reasons why
it would be equally hard to get good behavior from Perforce client-
side triggers, were Perforce to implement them.

You said you weren't arguing particularly for or against client-side
triggers; from my perspective, you were arguing quite effectively
against :-)

Cheers,
Rob

_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Rob Jellinghaus]

I just thought of a counterexample to my own argument, here:
p4win is totally unextensible right now. Other folks have
asked for a way to add commands to p4win (i.e. "execute
script X on the selected file(s)"); it would be equally good
to have a way to have p4win invoke a p4 wrapper script
instead of the raw p4 command. Then you could implement
your p4 wrapper script to do whatever you locally want, and
p4win could just use that instead. This is still not quite
like munging p4 itself to support script invocation, but
it's a step down a slippery slope....

Cheers,
Rob

-----Original Message-----
From: Rob Jellinghaus [mailto:***@quokka.com]
Sent: Monday, April 17, 2000 11:56 AM
To: 'Jeff A. Bowles'; Chuck Karish
Cc: Rajul Vora; perforce-***@perforce.com
Subject: RE: [p4] Client-Side Submit Triggers


From: Jeff A. Bowles [mailto:***@pobox.com]
>At 3:16 PM -0700 4/14/00, Chuck Karish wrote:
>>What functionality do you want that you can't get with a
>>wrapper for p4.exe or by writing a tool using the p4 API?
...
>For example, a client-side trigger that says "check for an
>object file that has a date newer than the file getting
>checked in" is a *very* basic "did it compile?" test. Not
>a very good one, mind you, but still it's better than
>nothing. (This is something a server-side trigger cannot do.)
...
>The reason a hack to "p4.exe" (or a wrapper) or using the P4 API
>isn't sufficient do these sort of things is that you want to ensure that
>this 'trigger' behavior is run every time, not just when the
>developer runs "the right client executable/program" to do
>the submit. That is, by the way, one reason that client-side
>triggers aren't there at the moment, I suspect: how can you
>CLEANLY guarantee that the client-side trigger is ALWAYS run
>on the platforms it's supposed to, and that it has access to
>the right tools to do its job? (For example, do you want to
>assume that check-ins from a platform that lacks a C compiler
>are good? Are never good? There be dragons there....)

I think you've just summarized the reason why Perforce shouldn't
even really *try* to implement client-side triggers.

Getting the p4 command itself to be portable is hard enough. I
can see little or no way Perforce could integrate client-side
extensible scripting (which is sort of what you're asking for)
into the portable p4 command. Consider all the variants: do you
want to run a DOS batch file? a Unix shell script? a Perl script?
Are you on Windows? BeOS? Macintosh? What are the exit code
conventions? Can every type of script even return the right sorts
of exit codes? There's far too much local variation here.

What prevents you from setting up your clients' environments such
that the raw p4 tool is completely inaccessible? You're *always*
in a situation where the developer needs to run "the right client/
executable program" to do the submit. The big issue is whether
you provide two ways to do it--the right way, via myp4wrapper or
whatever, and the wrong way, via raw p4--or whether you only
provide one way, namely myp4wrapper, and contrive to hide the raw
p4 command altogether. Again, the details of how you would do this
are specific to your OS, your procedures, and your preferred
support tools, which all argues against Perforce trying to solve
this particular worm can.

>And to anyone who says "but ClearCase has 'em" (and it does),
>I'd respond: yes, but getting *consistent* and *helpful* behavior
>from 'em is no fun.

I suspect that the reasons why this is so are the same reasons why
it would be equally hard to get good behavior from Perforce client-
side triggers, were Perforce to implement them.

You said you weren't arguing particularly for or against client-side
triggers; from my perspective, you were arguing quite effectively
against :-)

Cheers,
Rob

_______________________________________________
perforce-user mailing list - perforce-***@perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

[Rajul Vora]

Actually, things would be a lot simpler if p4 and p4win both loaded the API
library dynamically instead of statically linking it in. Then, one would
have to just change the API (the engine). This would also work for p4web
arguably.

Rajul

> -----Original Message-----
> From: Rob Jellinghaus [mailto:***@quokka.com]
> Sent: Monday, April 17, 2000 12:10 PM
> To: Rob Jellinghaus; 'Jeff A. Bowles'; Chuck Karish
> Cc: Rajul Vora; perforce-***@perforce.com
> Subject: RE: [p4] Client-Side Submit Triggers
>
>
> I just thought of a counterexample to my own argument, here:
> p4win is totally unextensible right now. Other folks have
> asked for a way to add commands to p4win (i.e. "execute
> script X on the selected file(s)"); it would be equally good
> to have a way to have p4win invoke a p4 wrapper script
> instead of the raw p4 command. Then you could implement
> your p4 wrapper script to do whatever you locally want, and
> p4win could just use that instead. This is still not quite
> like munging p4 itself to support script invocation, but
> it's a step down a slippery slope....
>
> Cheers,
> Rob
>
> -----Original Message-----
> From: Rob Jellinghaus [mailto:***@quokka.com]
> Sent: Monday, April 17, 2000 11:56 AM
> To: 'Jeff A. Bowles'; Chuck Karish
> Cc: Rajul Vora; perforce-***@perforce.com
> Subject: RE: [p4] Client-Side Submit Triggers
>
>
> From: Jeff A. Bowles [mailto:***@pobox.com]
> >At 3:16 PM -0700 4/14/00, Chuck Karish wrote:
> >>What functionality do you want that you can't get with a
> >>wrapper for p4.exe or by writing a tool using the p4 API?
> ...
> >For example, a client-side trigger that says "check for an
> >object file that has a date newer than the file getting
> >checked in" is a *very* basic "did it compile?" test. Not
> >a very good one, mind you, but still it's better than
> >nothing. (This is something a server-side trigger cannot do.)
> ...
> >The reason a hack to "p4.exe" (or a wrapper) or using the P4 API
> >isn't sufficient do these sort of things is that you want to
> ensure that
> >this 'trigger' behavior is run every time, not just when the
> >developer runs "the right client executable/program" to do
> >the submit. That is, by the way, one reason that client-side
> >triggers aren't there at the moment, I suspect: how can you
> >CLEANLY guarantee that the client-side trigger is ALWAYS run
> >on the platforms it's supposed to, and that it has access to
> >the right tools to do its job? (For example, do you want to
> >assume that check-ins from a platform that lacks a C compiler
> >are good? Are never good? There be dragons there....)
>
> I think you've just summarized the reason why Perforce shouldn't
> even really *try* to implement client-side triggers.
>
> Getting the p4 command itself to be portable is hard enough. I
> can see little or no way Perforce could integrate client-side
> extensible scripting (which is sort of what you're asking for)
> into the portable p4 command. Consider all the variants: do you
> want to run a DOS batch file? a Unix shell script? a Perl script?
> Are you on Windows? BeOS? Macintosh? What are the exit code
> conventions? Can every type of script even return the right sorts
> of exit codes? There's far too much local variation here.
>
> What prevents you from setting up your clients' environments such
> that the raw p4 tool is completely inaccessible? You're *always*
> in a situation where the developer needs to run "the right client/
> executable program" to do the submit. The big issue is whether
> you provide two ways to do it--the right way, via myp4wrapper or
> whatever, and the wrong way, via raw p4--or whether you only
> provide one way, namely myp4wrapper, and contrive to hide the raw
> p4 command altogether. Again, the details of how you would do this
> are specific to your OS, your procedures, and your preferred
> support tools, which all argues against Perforce trying to solve
> this particular worm can.
>
> >And to anyone who says "but ClearCase has 'em" (and it does),
> >I'd respond: yes, but getting *consistent* and *helpful* behavior
> >from 'em is no fun.
>
> I suspect that the reasons why this is so are the same reasons why
> it would be equally hard to get good behavior from Perforce client-
> side triggers, were Perforce to implement them.
>
> You said you weren't arguing particularly for or against client-side
> triggers; from my perspective, you were arguing quite effectively
> against :-)
>
> Cheers,
> Rob
>
> _______________________________________________
> perforce-user mailing list - perforce-***@perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>

[Paul Goffin]

Like you, I'd love to be able to check
for "$Id:"/"$Header:" - and I think this
is best done on the server. As you
say this would be fixed if the
trigger had access to the files.

But regarding letting users have thier
own server triggers - I think this could be done.

Why not have an extension to the "user"
definition to include "user triggers"?

True, the user would need access to
somewhere on the server filespace to
actually store his(her) executable - but that
area need not be shared.

It seems to me that the server would then
need to execute user triggers before
"global" triggers - otherwise the user
could implement triggers that broke the
global policy.

> -----Original Message-----
> From: Frank Merrow [mailto:***@qualcomm.com]
> Sent: 17 April 2000 20:07
> To: perforce-***@perforce.com
> Subject: Re: [p4] Client-Side Submit Triggers
>
>
> At 11:28 AM 4/17/00, you wrote:
> >At 3:16 PM -0700 4/14/00, Chuck Karish wrote:
> >>What functionality do you want that you can't get with a
> >>wrapper for p4.exe or by writing a tool using the p4 API?
>
> Actually, I can name you another one, in fact several:
>
> As P4 Admin:
>
> On check in, check to see if the file contains $Header:$ or $Id:$ and
> refuse to allow the check in if "Keywords" aren't enabled in
> the File_Type.
>
> This is a common developer problem I'd like to fix with a client side
> trigger of some kind. As it stands now, the best I can to is
> to ask the
> Depot for the PREVIOUS version and see if the keyword is
> there. However,
> I'm sure you understand why I consider this less than optimal.
>
> As P4 Developer:
>
> As a developer, I'd really like to add to triggers to scan my
> code for
> certain problems. Is the Qualcomm Copyright present? If so,
> has it been
> updated to the current year. Are current coding standards
> proper for the
> current file?
>
> These vary from group to group within the company so a Depot
> wide trigger
> isn't a good solution. However, as a developer I can think
> of lots of
> reasons to Quality Check my code and prevent check in if
> certain things
> haven't been done.
>
> One thing you'll notice with BOTH examples . . . the problems
> they are
> trying to solve could still be done with server side triggers if the
> UPDATED FILES were available on the server when the trigger
> was running,
> but before they were actually checked into the archive. The
> fact that the
> files are not available to the triggers is a repeatedly inconvenient
> problem IMHO.
>
> However, even if you did to a TEMP copy of the new files and
> make that
> available to the triggers (a great idea all by itself), as a
> developer, I'd
> still like to have client side triggers than I can control.
> No P4 Admin
> worth his salt is going to allow 15 developers to be mucking
> about on the
> company's depot all the time to tinker with their personal
> triggers. You
> need a trigger that the USER can install and manage, but that
> the Admin
> doesn't have to fret about all the time.
>
> Frank
>
>
> _______________________________________________
> perforce-user mailing list - perforce-***@perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>

[Peter Nann]

I am new to Perforce, and haven't looked at triggers in detail
yet, but the gist of this thread disturbs me:
If only server side triggers (i.e. Post submit?) are available,
and they don't have access to the submitted files, it seems the
usefulness of triggers is pretty damned limited.

How the heck can you automatically and reliably enforce coding
standards without one of either client side triggers, or server
side with access to files?
(Besides the obvious (?) nasty hacks of server triggers 'finding'
the client files somewhere...).

I vote whole heartedly for either:
*) Access to files in server triggers, or
*) Client triggers.

Otherwise, Perforce won't be able to do some things I just
assumed it would be able to do!
(Eg, check for consistant end-of-line termination, copyright
inclusion, tab indentation versus space, etc)

Or am I just an ill-informed newbie?

--
Peter Nann Systems Architect ***@syrinx.com.au
Syrinx Speech Systems Australia www.syrinx.com.au
Phone:+61 [0]2 9925-0477 Fax:+61 [0]2 9925-0761
Level 8, 132 Arthur St, North Sydney, NSW, 2060, Australia
--------
"The most productive technologies are those that disappear. They
wear themselves into the fabric of everyday life until they are
indistinguishable from it."
- The late Mark Weiser, Xerox PARC.