« November 27, 2005 - December 3, 2005 | Main | December 11, 2005 - December 17, 2005 »
Updated BinMerge to always draw the merge arrow to the branch we are merging to. There was also a bug about the choice returned from the PerlTk portion where it needed to not only be chomped but chopped until there were no more "\n"'s there. Don't know why that happened.
Additionally the PerlTk window would often not pop to the top of the window stack. This is apparenty common under Windows. I implemented the following code:
# Make sure the window pops to the top
# Trying really hard... :-)
$main->update;
$main->deiconify;
$main->update;
$main->raise;
$main->update;
$main->focusForce;
$main->update;
MainLoop;
At least this heavy handed approach seems to work.
Ravi and I worked on the stripmimed thing a little today. Here's what happened:
I attempted to debug this further and I made a change /tools/gnats/4.0/bin/stripmimed and now:
gnats-irva-3:/tools/gnats/4.0/bin/stripmimed /tools/gnats/4.0/bin/stripmimed: line 44: use: command not found /tools/gnats/4.0/bin/stripmimed: line 48: use: command not found /tools/gnats/4.0/bin/stripmimed: line 49: use: command not found /tools/gnats/4.0/bin/stripmimed: line 50: use: command not found /tools/gnats/4.0/bin/stripmimed: line 51: use: command not found /tools/gnats/4.0/bin/stripmimed: line 52: use: command not found /tools/gnats/4.0/bin/stripmimed: line 54: undef: command not found /tools/gnats/4.0/bin/stripmimed: line 56: my: command not found /tools/gnats/4.0/bin/stripmimed: line 57: my: command not found /tools/gnats/4.0/bin/stripmimed: line 58: my: command not found /tools/gnats/4.0/bin/stripmimed: line 60: open: command not found /tools/gnats/4.0/bin/stripmimed: line 61: or: command not found /tools/gnats/4.0/bin/stripmimed: line 63: sub: command not found /tools/gnats/4.0/bin/stripmimed: line 64: my: command not found /tools/gnats/4.0/bin/stripmimed: line 66: print: command not found /tools/gnats/4.0/bin/stripmimed: line 67: syntax error near unexpected token `}' /tools/gnats/4.0/bin/stripmimed: line 67: `} # Log'
So how did we fix the shebang problem before? Also, why is queue-pr not properly updating the pr? (My suspicion is that the file attachment on this PR is messing up queue-pr - nope, that doesn't seem to be it...
I decided to change bin_merge into a module (BinMerge) and use it in UCMCustom. I was having problems trying to start the bin_merge process and getting it going in a pipe so the output from verbose could give the user feed back. For some reason bin_merge has to exit before any output was returned. Might have been because of the $/ thing described below (Bad UCMCustom, bad!)
I've been taught that both use strict and use warnings should always be used when coding Perl. These diagnoistic routines are helpful in catching some common Perl mistakes that are otherwise much more difficult to debug. In fact, in implementing this I found a few potential bugs that I also corrected.
Note: Some version of Perl do not have use warnings. Instead specify -w on the #! line.
Require is old hat. Use is the new require! From Perldoc's What's the difference between require and use?:
What's the difference between require and use?
Perl offers several different ways to include code from one file into another. Here are the deltas between the various inclusion constructs:
- do $file is like eval `cat $file`, except the former
- searches @INC and updates %INC.
- bequeaths an *unrelated* lexical scope on the eval'ed code.
- require $file is like do $file, except the former
- checks for redundant loading, skipping already loaded files.
- raises an exception on failure to find, compile, or execute $file.
- require Module is like require "Module.pm", except the former
- translates each "::" into your system's directory separator.
- primes the parser to disambiguate class Module as an indirect object.
- use Module is like require Module, except the former
- loads the module at compile time, not run-time.
- imports symbols and semantics from that package to the current one.
Note that becuase use loads the module at compile time one need to arrange for the @INC array to have any paths needed for use to succeed (IOW user written modules). In order to accomplish this one need to seed the @INC arrray in a BEGIN block as BEGIN blocks are executed before use is expanded,
From Perldoc's Perlvar:
You should be very careful when modifying the default values of most special variables described in this document. In most cases you want to localize these variables before changing them, since if you don't, the change may affect other modules which rely on the default values of the special variables that you have changed. This is one of the correct ways to read the whole file at once:
open my $fh, "foo" or die $!; local $/; # enable localized slurp mode my $content = <$fh>; close $fh;But the following code is quite bad:
open my $fh, "foo" or die $!; undef $/; # enable slurp mode my $content = <$fh>; close $fh;since some other module, may want to read data from some file in the default "line mode", so if the code we have just presented has been executed, the global value of $/ is now changed for any other code running inside the same Perl interpreter.
After banging my head against stripmime all day I finally figured it out. It would work from the command line but not from sendmail! It turned out to be the fact that I was not setting output_dir rather deferring to cwd and in the context of sendmail and aliases I guess that won't do. Changed stripmime to call $parser->output_dir ("/tmp"). Ravi needs to test this then we can implement.
Tommy Kee was having problems with merging where the cleardiffmrg tool would not come up stating instead that it encountered and error. I had seen this sort of error before at Ameriquest but it was specifically with snapshot views and with views that were tagged with forward slashes (something that mktag allows but cleardiffmrg has a problem with). But here we were dealing with dynamic views and the view tags were with all backslashes (\).
However, UCMCustom.pl would call cleartool findmerge with a leading forward slash (e.g. /andy\path\to\search). I suspected that this leading slash might be causing the problem and eventual showed that it was indeed the problem. Shivdutt changed UCMCustom.pl to use a leading blackslash.
I called IBM/Rational support this morning to raise the priority on this one. The priority has been raised and IBM/Rational is investigating this more fully. Meantime they suggested, as a temporary workaround, to turn off checking of code pages. I've tried this:
$ installutil setdbcodepagetonochecking -dbset 2005.02.00 admin
*********************************************************
Starting test setdbcodepagetonochecking
*********************************************************
Note: setting the code page to 'no checking' can result
in data corruption. Please refer to the ClearQuest Release
Notes for more information.
Successfully set the code page to 'no checking'.
*********************************************************
Exit code 0 for test setdbcodepagetonochecking
*********************************************************
Note that this does not stop the CharacterSetValidation package from complaining! Turning off the CharacterSetValidation requires a schema change to return FALSE from enable_char_set_validation.
The problem occurs during a deliver between projects where there is a merge conflict and UCMCustom wants to have findmerge call up a Cleardiffmgr to resolve the conflicts. I've seen this before WRT snapshot views and view tags with forward slashes at Ameriquest. UCMCustom perfaces' the vob tags with "/".
But this problem doesn't always happen - in fact most of the time it appears to work. It might be just when there's a merge conflict
After working with Shivdutt and IBM/Rational on the problem and getting down to reproducing it with a long cleartool findmerge command in the user's environment this problem started happening to me in my test environment as I was integrating bin_merge. After much narrowing down I found:
Here's some more information. As you know I started having a similar problem as the end user. I paired it down to the following. This fails (but does not always fail):
Z:\andys_pvob>cleartool findmerge /andy\bin\cygwin_setup -fver \main\Andrew_Integration\6 -log NUL -gmerge -nc
Needs Merge "/andy\bin\cygwin_setup" [to \main\Andrew_Integration\Andrew2_Integration\CHECKEDOUT from \main\Andrew_Integration\6 base \main\Andrew_Integration\5]
However the following does work:
Z:\andys_pvob>cleartool findmerge \andy\bin\cygwin_setup -fver \main\Andrew_Integration\6 -log NUL -gmerge -nc
Needs Merge "\andy\bin\cygwin_setup" [to \main\Andrew_Integration\Andrew2_Integration\CHECKEDOUT from \main\Andrew_Integration\6 base \main\Andrew_Integration\5]
Notice the difference? It's subtle. The first findmerge's path starts with a "/" while the second one starts with a "\".
My bin_merge script remains it's own process. This will be useful if others wish to use this process. However UCMCustom needs to incorporate calling bin_merge. I'm currently having a problem with this because I want to start bin_merge as a pipe so I can give the user feedback. But bin_merge runs to completion before the first output is received. I don't know why this is happening as it doesn't happen in a smaller test.pl environment, only under the massive UCMCustom.pl...