« August 2007 | Main | October 2007 »
Meantime I spoke with John about this and Release Records and learned a little bit about them. From what I understand the work I did regarding config spec Switch Config files should more properly be moved to Release Records. John explained that in general there are 3 sections to config specs (well some config specs for some projects).
The first section is generated by the UCM process of creating UCM related views that have components. These are delineated by "ucm" and "end ucm" markers in the config spec.
After that are any custom rules that you may want. This is where Release Records come in. The whole WOR oriented Clearquest mechanism already knows about Release Records. They are actually stored in Clearquest and are added to the end of the config spec at view creation time (by createView.pl that is).
So what are Switch Config files (Nit: I don't like the term Switcher Config. The script is called switchConfig.pl not switcherConfig.pl...)? Well there are files which are stuffed into config specs after "end ucm" but before Release Records by the switchConfig.pl script.
However the intent of Switch Config files is to allow you to switch target type things (e.g. Solaris vs. PPC vs. SimCello) while the intent of Release Records was to specify which versions of the tools you want to use. So eventually, I will need to migrate the tools related lines from Switch Config files to Release Records.
Here's how I typically use FindBin:
use FindBin;
...
use lib "$FindBin::Bin/../lib";
...
sub Usage ($) {
my ($msg) = @_;
display "ERROR: $msg\n" if defined $msg;
display <<END;
Usage: $FindBin::Script [-usage] [-verbose] [-debug] [-exec]
-from_view <view> -label <label_name>
...
END
Also I tend to use Getopt::Long. It is extremely flexible. Options can be specified in the GNU long method as in --debug or just -debug. Additionally you can abbreviate as in -d IFF there is no other option that starts with "d". Options can have parameters (-file myfile.txt or -file=myfile.txt), set boolean (-verbose can set say $verbose), automatic negation (-verbose or -noverbose), even call subroutines directly!k Here's an example.
use GetOpt::Long;
...
my $execute = 0;
my $from_view; # e.g. p6258c_RAN_FDD_Doc_Bld1_int
my $branch; # e.g. ran_fdd_release_build2_integration
my $label; # e.g. RAN_FDD_RELEASE_BUILD1
GetOptions (
"usage" => sub { Usage "" },
"verbose" => sub { set_verbose },
"debug" => sub { set_debug },
"exec!" => \$execute,
"from_view=s" => \$from_view,
"branch=s" => \$branch,
"label=s" => \$label,
) || Usage "Unknown parameter";
Some notes about the above:
A word on Display.pm:
I find that often people do the following:
print "In myspecial_subroutine: File = $file\n" if $debug;
for debugging. To me it's always been a hassle to have to remember to include the "\b" and the "if $debug", etc. Granted that's not a lot. But how can I make it better?
My thought was to name the procedure debug and include the "\n" by default. People oughta quickly discern that:
debug "In myspecial_subroutine: File = $file";
probably only happens when debugging.
Additionally I support routines like verbose, debug, error, warning (from Display.pm).
It never ceases to amaze me what some programmers do that when I look at it seem to be just foolish things. Here's today's example:
In ucmwb a bug was discovered when a user first su's to some other user then runs ucmwb (in this case the user is su'ing to ccadm). The while the main window dutifully displays the list of WORs for the su'ed user, the view browser does not. Instead it displays the list of views for the original user. Turns out that there was specific code for Solaris to call cuserid instead of getenv("USER"). So Linux was working but Solaris failed. Why the difference?
But along with that I noticed the following code:
QSting homePath = QDir::homePath();
if (homePath.isEmpty()) {
qDebug() << "homePath is empty!";
// Note the following is a Unix'ism and non portable!
homePath = QString("/home/") + appUsername;
}
qDebug() << "homePath = " << homePath;
QString settingsFilename = QDir::homePath() + QString("/.ucmwbrc");
QString settingsDirname = QDir::homePath() + QString("/.ucmwb.d");
QString filterFilename = settingsDirname + QString("/filters");
OK so first ask yourself what do you see wrong here.....?
Pencils down!
Here's my questions:
Naturally I fixed this to be:
QSting homePath = QDir::homePath();
if (homePath.isEmpty()) {
// Note the following is a Unix'ism and non portable!
homePath = QString("/home/") + appUsername;
}
QString settingsFilename = homePath + QString("/.ucmwbrc");
QString settingsDirname = homePath + QString("/.ucmwb.d");
QString filterFilename = settingsDirname + QString("/filters");
Process was written to perform this importation. The process takes 3 parameters: a from_view, a branch and a label. The process is designed to run in the to_view context. It proceeds to search the from_view for elements that do not exist in the to_view and upon finding them it merges the parent directory and then the element in question is "imported".
Both a branch and a label is used because the merge procedure used on directory elements first tries to merge with the LATEST on the specified branch. If the branch does not exist (because the element was never branched) then the label is used to locate the source directory for the merge.
File elements aren't merged - they are imported (i.e. copied from the from_view to the to_view)
There are a few errors and/or warnings that can result in such a process that this script cannot hueristically determine the correct action to take. The problems arise from the renaming or removing of elements in the to_view. It is not possible for this script to determine what the user intended. An example will better explain this.
For build 1 there was a directory named:
/vobs/gdrandocs/development/proj/ran/fdd/RNC_Initialization_Configuration
This was on the ran_fdd_doc_bld1_integration branch version 2 which was labled RAN_FDD_RELEASE_BUILD1. At version 17 RNC_Intitialization_Configuration was renamed to RBS_RNC_Intitialization_Configuration. By version 28 the RAN_FDD_RELEASE_BUILD2 label was applied.
Since this directory was renamed there is no way to guess what it was renamed to. Sure it's easy for a human to look at it and make a loose association based on the fact that most of the directory name is the same, this sort of AI is very difficult to program. The script marks these as an error. It's an error because somebody should verify if a directory was simply renamed or if it was removed (rmname'd). Also it's not known what to do at this point. Shall we assume that the newly named directory contains all it needs? Or does further merging/importing need to take place?
Additionally, since a directory is renamed, the elements contained in the directory went along with it. So in the script, the from_view keeps producing paths with RNC_Intitialization_Configuration in them not RBS_RNC_Intitialization_Configuration. Such elements then appear to have disappeared and the script issues a warning for these. At this point we really cannot tell if the file element was simply removed (where we would assume that the act was deliberate and that we should not be importing the element back in) or if it's a result of a directory renaming of the parent directory (or some parent of the parent) thus falling into the error described in the preceeding paragraph.
Annoyingly backspace continues to be a problem, especially with Sun. Here's the fix for vim (put in ~/.vimrc):
set t_kb=^h fixdel
Note: That's a Control-V [backspace] to produce ^h.
Created a Perl script to handle the odd findmerge like "bring documents into visibility" help desk tickets. It's like a findmerge however we don't want to merge any elements - just merge in the previously unseen elements. A rough outline of the algorithm is as follows:
foreach my $from_element (@elements_from_the_from_view) {
next if -e $from_element
<merge parent directory>
next if -d $from_element;
copy $from_element -> $to_element
}
It's also been discussed that the group has not decided exactly what documents should be imported in from the original set. Importing from build 1 -> build 2 doesn't make much sense. IOW we should start from the beginning.
I know everybody's busy however could you please take a few moments to help verify this new release of ucmwb 1.2.3. The following is a list of 12 tickets resolved in this release along with a little description telling you what was fixed and how you can verify it. You can run ucmwb from the command line to run ucmwb 1.2.2 and ucmwbpre from the command line to run the new ucmwb 1.2.3. This way you can do a side by side comparison.
There are a few tickets that have not been addressed for this release because they require a lot more effort to implement but I would like to release 1.2.3 and knock out a bunch of tickets.
Finally there remains a licensing issue for Qt upon which ucmwb is built. The licensing has been approved and the next step needs to take place...
Status: Fixed in 1.2.3
To reproduce:
RANCQ00011414: UCMWB create view with common target dev WOR incorrectly creates new stream
RANCQ00011424: UCM Workbench doesn't create the correct stream for Target WORs
RANCQ00012828 Fix shared stream view creation from UCM Workbench.
Status: Fixed in 1.2.3
To reproduce:
RANCQ00012827: Many developers are getting deliver issue where default view is not found.
Status: Verified not a problem.
This merely verifies that duplicate stream views are not being created by ucmwb (neither 1.2.2 nor 1.2.3 did this).
RANCQ00012829: View creation issue against Collector WORs
Status: Verified not a problem.
This merely verifies that ucmwb does not allow creation of views for Collector WORs.
RANCQ00013782: ucmwb defect - does not delete view when rebase pending
Status: Fixed in 1.2.3
When deleting a view, stderr from the cleartool rmview is now displayed if there were any errors. This covers both the rebase problem and deliver problems...
To reproduce:
Deletion of view now fails properly indicating that you cannot delete the view while it's in the middle of a rebase/deliver. User can return to ucmwb, select view and rebase stream then undo or complete the rebase, then deletion of the view will work.
RANCQ00014267: UCMWB should save Clearquest password so it doesn't need to be constantly specified
Status: Fixed in 1.2.3
To reproduce:
Note that the password is saved only for the duration of the ucmwb session. Saving it in preference would involve encryption/security concerns.
RANCQ00014268: UCMWB Save Activity List improvements
Status: Fixed in 1.2.3
To reproduce:
Note: The part about adding .html is more problematic than initially anticipated and therefore not addressed.
RANCQ00014402: UCMWB should unset activity before deleting the view
Status: Fixed in 1.2.3
To reproduce:
ucmwb 1.2.2 did not bother to unset the view's activity when a view was deleted. As a result Clearquest was never updated WRT its association of that just deleted view with this activity. User could not therefore use ucmwb to create a view for that WOR anymore!
RANCQ00014935: Allow the UCM Workbench to create WOR from Collector
Status: Not fixed
This issue involves a much more complicated interaction between ucmwb and Clearquest than is currently capable. Code exists in ucmwb to use cqtool (which is going away at 7.0 BTW) to pop up the submission dialog box from Clearquest. While this will allow a WOR to be created, the trouble is 1) it's non blocking and 2) the newly created WOR # is not returned, thus we do not know how to do the linking required by this request.
A totally different approach is needed, one that will solve a few other issues such as being able to offer a way to create WORs (not just child WORs nor Collector WORs but just normal WORs) directly from ucmwb - which would make ucmwb much more useful, but might be able to solve the problem with cqtool going away for 7.0. If we could reliably create WORs in ucmwb by interacting with a Perl process talking to Clearquest, then the above ticket only involves performing the link afterwards.
RANCQ00015381: Port UCMWB to Linux
Status: Fixed in 1.2.3!
To reproduce:
Also exhibits that ucmwbpre (actually /prj/muosran/bin/ucmwbpre) is a shell script which kicks off the correct binary based on architecture.