[p4] Modifying Changelist form

Matt Janulewicz Matt.Janulewicz at lucasfilm.com
Sat Aug 22 00:36:58 PDT 2009


This might be a crazy idea, and maybe others can support or refute it.

A few companies ago we were headed down this road. Then we realized that most of the 'fields' we wanted in the description were fields that already existed in our bug tracker. So why not marry these up?

I'm always weary of being too rigid with the check-in comments, as it's just a large text field and isn't really designed to be dynamic. (Is a change going to be "Unit Testing Done: no" forever? How would you change that? Down the line?) Plus, as alluded to by others, you stand a chance of mucking up the script and double-entering information, etc. Debugging this kind of thing while people are not able to check in their work will cause some bad PR, at the very least, for you.

Lastly, in my experience, presenting someone with a pure-text form that one has to tab around and enter stuff in is annoying. Developers hate roadblocks, no matter how small they seem. They want to submit their work.

Now Jobs offer a form where you can have custom fields, fields that change, fields that are mandatory, etc., and a very easy way to attach them to changelists. It's very easy to 'triggerize' mandatory jobs for submissions. It's also then very easy to apply that trigger to specific areas of your depot(s) without making this a global thing. In a year you might decide that your form doesn't apply to certain projects, but by that time you've painted yourself into a global corner.

Even if you don't hook Jobs up to an issue tracker, I think they can be useful in this case. I always vote for doing things the easier way, using built-in functionality. And Jobs provide a somewhat arbitrary form, with fields, that you can do with what you will. The overhead on the trigger will be much smaller and as mentioned, it may not even fire off in every case. Plus it's supported Perforce functionality that would use a minimum of background programming (and thus troubleshooting.)


-Matt


-----Original Message-----
From: perforce-user-bounces at perforce.com on behalf of Kamlesh Mutha
Sent: Fri 8/21/2009 11:56 PM
To: Ivey, William
Cc: Perforce Users Mailing List
Subject: Re: [p4] Modifying Changelist form
 
Looks like, I will end up collecting all that information in changelist form
itself. Since intention is not to verify everything that is being entered
there in the form, this mechanism should work well without affecting
perforce server performance.

Regards,
Kamlesh



On Fri, Aug 21, 2009 at 8:49 PM, Ivey, William <william_ivey at bmc.com> wrote:

>  Not really, but you can reject the submit with an explanation of which
> fields
>
> were not properly filled out. By the way, in cases like this I always
> provide
>
> an override, usually in the form of a comment, for example: # OVERRIDE
>
> because there will always be cases where the normally required information
>
> is not applicable. You can have the trigger insert a statement into the
>
> description that the use overrode the trigger.
>
>
>
> Keep in mind that you don't want to tie up the submit process too long,
>
> and you don't want triggers to fail and reject perfectly valid submits. So
>
> you want to make them fast and robust, and if an internal error occurs
>
> I usually have the trigger return success on the theory that failing safely
>
> means accepting the submit even if it can't be properly checked.
>
>
>
> -Wm
>
>
>
>
>  ------------------------------
>
> *From:* Kamlesh Mutha [mailto:mkamlesh at gmail.com]
> *Sent:* Friday, August 21, 2009 2:46 AM
> *To:* Ivey, William; Perforce Users Mailing List
> *Subject:* Re: [p4] Modifying Changelist form
>
>
>
> Just a step ahead, I want to get some more information from User for each
> submission.
>
> Something like:
>
> Backlog / Feature Description:
>
> Change Description :
>
> Code reviewed by:
>
> Unit Testing done : Yes / No
>
> Klockwork run : Yes / No
>
>
>
> This text can also be included in the change form as discussed before in
> this thread.
>
> But can we have some additional form which will pop up at the time of
> submit/changelist creation, with all such questions so that we have
> information related to any change stored on perforce server.
>
>
>
> Thanks and Regards,
>
> Kamlesh.
>
>
>
>
>
>
>
> On Tue, Aug 11, 2009 at 10:48 PM, Ivey, William <william_ivey at bmc.com>
> wrote:
>
> My "reviewer" trigger looks for the the string that's normally
> only found in new change forms: "<enter description here>" so it
> won't add the "reviewed by" line again to an existing change
> form. It's written for bourne shell (standard for our triggers)
> and uses the sed command, but otherwise it is very similar to
> what you have:
>
> sed -e "s/<enter description here>/&\n\n# Fill in reviewer's name\
>  below\nReviewer: <name>/" "$formFile" > "$TMPFILE"
>
> (The & inserts the matched text, then follows it with a blank
> line, a comment, and the Reviewer: field.
>
> -Wm
>
>
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com [mailto:
> perforce-user-bounces at perforce.com] On Behalf Of Kamlesh Mutha
>
> Sent: Saturday, August 08, 2009 3:39 AM
> To: Perforce Users Mailing List
> Subject: [p4] Modifying Changelist form
>
> Hi All,
>
> Objective is to insert "ReviewedBy" field text in every changelist form.
> This is what I have done and seems to be working fine in my test setup.
>
> Trigger Script:
>
> #!/usr/bin/perl
> $formfile = $ARGV[0];  # from %formfile% in trigger table
>
> $defaultin = "^Description:";
> $defaultout = "Description:\n\tReviewedBy =>\n";
>
> # Build a modified workspace spec based on contents of %formfile%
> $modifiedform = "";
> open FORM, $formfile or die "Trigger couldn't read form tempfile";
> while ( <FORM> )
> {       ## Do the substitution as appropriate.
>        if ( m:$defaultin: ) { $_ = "$defaultout"; }
>        $modifiedform .= $_;
> }
> # Write the modified spec back to the %formfile%,
> open MODFORM, ">$formfile" or die "Couldn't write form tempfile";
> print MODFORM $modifiedform;
> exit 0;
> [ Snippet of the script from perforce site ]
>
> Triggers setup :
>
> Triggers:
>        reviwer form-out change "/home/builduser/modify_change.pl
> %formfile%"
>
>
> Does this look alright or is there any better way to do it?
>
> Thanks and Regards,
> Kamlesh
>
>
>
>
>
> --
> Faith waiting in the heart of a seed promises a miracle of life which it
> can
> not prove!
> -Ravindranath Tagore
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>
>
>
> --
> Faith waiting in the heart of a seed promises a miracle of life which it
> can not prove!
> -Ravindranath Tagore
>



-- 
Faith waiting in the heart of a seed promises a miracle of life which it can
not prove!
-Ravindranath Tagore
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user





More information about the perforce-user mailing list