[p4] Triggers

Todd Blanchard todd.blanchard at cacheon.com
Tue Apr 23 09:52:51 PDT 2002


Doing the wrong thing very fast is not as good as doing the right thing
more slowly.

Development priorities are:
1) make it work
2) make it work right
3) make it work fast

I think P4 needs to get to 2 before working on 3.

Some things to keep in mind:
Databases seem to manage OK with triggers and they do all work on the
server.

The P4 server is probably a bigger machine than the client and in a
moderately sized
development environment it likely spends the vast majority of its time
eating out of its nose.

Finally, in an environment of disparate clients, its not too easy to get
identically functional implementations of the trigger for each platform.

As regards the other issue on diff - if the read hook gets a chance to
modify the stream to the client, then the client sees a completely
consistent view of the files and diffs work better than if I run my own
code formatter on my files on the client myself.

-----Original Message-----
From: Paul Goffin [mailto:PGoffin at baltimore.com]
Sent: Tuesday, April 23, 2002 2:30 AM
To: Todd Blanchard; perforce-user at perforce.com
Cc: support at perforce.com
Subject: RE: [p4] Triggers


> What P4 really needs are read and write hooks that allow file 
> processing
> as things are put on or read from the server.  I am utterly 
> amazed that
> this is lacking in the product.  It seems elemental.  Since 
> there are a
> mix of clients, the only appropriate place to put this 
> processing is on
> the server itself.


Perforce resist this as it goes against the main architecture
of Perforce - that is its design for _speed_.

The argument goes that the slowest part of any check in is
the copying of files from the client to the server.  Perforce
optimises this by (amongst other things) only doing this transfer
when the submission is guaranteed to succeed (i.e. all files are
locked & all triggers have passed).

If files had to be transfered to the server _before_ triggers ran,
there is a concern that this would seriously affect performance.
(As files would be transfered, fail a trigger, then the submission
would be repeated, etc.)

Paul.


------------------------------------------------------------------------
-----------------------------------------
The information contained in this message is confidential and is
intended 
for the addressee(s) only.  If you have received this message in error
or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, 
special, indirect or consequential damages arising from alteration of
the 
contents of this message by a third party or as a result of any virus
being 
passed on.
 
This footnote confirms that this email message has been swept for
Content
Security threats, including computer viruses.

http://www.baltimore.com




More information about the perforce-user mailing list