[p4] Trigger to automatically change content when submitted

[Robert Buck]

One of the big issues we are having with both CVS and p4 is LF's. We
have thousands of files that have mixed LF conventions (Mac + UNIX +
Win). It creates lots of problems with code generators. One thing I was
hoping to do was run mac2unix and dos2unix in a trigger to force it to
UNIX format neutralizing any significant downstream impact.

My thought was to, as Mathew said, "have Perforce do as much of your job
as possible."

Bob

> -----Original Message-----
> From: Matthew Janulewicz [mailto:MJanulewicz at greendotcorp.com] 
> Sent: Tuesday, May 16, 2006 1:43 PM
> To: Wright, Richard; Paul Goffin; Weintraub, David; Robert 
> Buck; perforce-user at perforce.com
> Subject: RE: [p4] Trigger to automatically change content 
> when submitted
> 
> I have to agree that it is a good idea to sometimes reject a checkin.
> Why bother having coding standards, code review requirements 
> or unit testing requirements if they aren't checked?
> 
> At a former place of employ we required that no broken code 
> be checked into the production branches. How? We had a 
> requirement that nunit results were checked in with the code. 
> We had a trigger to reject code to production branches that 
> didn't pass unit tests. Why bother waiting until CM builds 
> it, having it fail, walk over to the developer (if you could 
> figure out who broke it), ask them to fix it, etc. etc. 
> Garbage in, garbage out. Have Perforce do as much of your job 
> as possible. :)
> 
> We also had a requirement for code review when something went 
> to production. How did we do that? We required a bug (job) to 
> be attached to code when it was submitted to the production 
> codeline. No job? No checkin.
> 
> These are just two of many good reasons to reject a checkin. 
> Keeping in mind that this was just for production code, not 
> everyday code. I agree that it could easily get out of hand 
> and ridiculous. These were the only two requirements we had 
> for checkins and I found that the developers got used to it 
> very quickly and found it harder to circumvent the process we 
> laid out. The result was better process, better software, 
> less regression and a heck of a nice package when the FDA 
> came for audits.
> 
> I'd much rather prevent the circumvention of process at the 
> point where it could happen, rather than have to come back 
> and clean it up later. I don't have time for that, but I do 
> have time to write a few triggers now and again. Plus, as 
> alluded to above, when the FDA comes knocking in to audit 
> you, saying 'We were getting to that' doesn't cut it.
> 
> 
> -Matt
> 
> 
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of 
> Wright, Richard
> Sent: Tuesday, May 16, 2006 9:03 AM
> To: 'Paul Goffin'; Weintraub, David; Robert Buck; 
> perforce-user at perforce.com
> Subject: Re: [p4] Trigger to automatically change content 
> when submitted
> 
> I disagree that it is never a good idea to reject 
> submissions, although I would tend to restrict those 
> rejections mainly to release branches.  In other words, 
> ideally there should be a place where they can "always"
> check
> in, even if there are rules around certain branches.
> 
> I do, however, agree that you need to make it easy to do 
> things the right way, or you will get people trying to get 
> around the system.
> 
> Now on fairly recent servers, there is an interesting way of "Nagging"
> for
> things like this:
> Set up a "commit" trigger that will fail if the copyright is 
> not in place.
> By failing the commit trigger, you will still get a pop-up in 
> P4V with an error message, but the submit will still succeed. 
>  You just need to be careful with order when you do something 
> like that.  If you had a different commit trigger that sent 
> review emails, you would need to make sure that one ran first 
> or the failure would prevent the other trigger(s) from running.
> 
> -Rick
> 
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Paul Goffin
> Sent: Monday, May 15, 2006 11:13 PM
> To: Weintraub, David; Robert Buck; perforce-user at perforce.com
> Subject: Re: [p4] Trigger to automatically change content 
> when submitted
> 
> I agree with most of what David wrote, but have this comment:
> 
> >The best solution is a trigger that checks the files before being 
> >submitted for the condition you want, and rejects the submission if 
> >that condition isn't met. For example, let's say you state that the 
> >word "copyright" (small "c") must be in the first four lines of all 
> >text
> 
> I don't think it's ever a good idea to reject submissions to 
> the depot.
> 
> If you start putting barriers in front of your developers so 
> that the process of "Doing Things The Right Way" becomes 
> increasingly difficult, they will look for (and find) easier 
> ways of doing things.  (They're generally clever people, after all.)
> 
> Soon, your source repository will not actually contain the 
> source of the product you're actually shipping.
> 
> (In this particular case, with a customer screaming for a 
> vital fix for his product, what senior manager will demand 
> the release is held up for an extra week while the product is 
> retested because the source code had to be changed after code 
> freeze because someone forgot to change the copyright message 
> in a couple of files?  No, they'll support short-cutting the system.)
> 
> IMHO, the "right" way to do this is to implement a "Nagging" process.
> Review the code _after_ sumbission and send out emails to the 
> submitter and the codeline owner.
> 
> Paul
> 
> 
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 
> 
>