Status for Andrew DeFaria

• Caught up on build notes for 20050425, 20050519 and 20050525 for LW LOS178
• Resolved CR 41
• Tagged tst's for LW LOS178
• Assisted Adisak with lists for CRs 536 and 584

Posted by at 6:09 PM | Permalink

• Incorporated CR 598 which fixes the production build
• Tagged LW LOS178 20050525, rebuilt, released
• Ported CR 598 to GD
• Tagged GD LOS178 20050525, rebuilt, released
• Created build_notes for GD 20050428
• Associated updating of related CRs

Posted by at 6:38 PM | Permalink

• Was unable to build ppd_pdn due to a bug
• Found a bug in cvs_report regarding new directories

cvs_report bug

The cvs_report script determines what has changed by using cvs update, just like the old one. But it uses -n to not actually update the area. If it did actually update it then it would have to downdate it (for lack of a better term) for the next night's run. But there is a side effect to not doing the actual update: If there is a new directory the -n will prevent cvs update from looking into what's in the new directory! I did not know this.

This effects CR #570 and possibly others. CR #570 adds a new directory under src/lib/libm called complex with 52 new files. These files did not get included in the list of files to port over.

Additionally cvs_report had an error in a regex such that it was not identifying these new files properly. This has also been fixed.

Posted by at 6:30 PM | Permalink

Both files4ecr and files4cr will suffer this same problem. Let's say we had an E/CR with 10 files modified. If at some later time one of these 10 files is changed, or another file modified with this same E/CR number it will show up in the CVS Report as only that one file modified since the CVS Report goes from some base tag to some other tag (e.g. head). The difference between those tags is only that one file - rightfully so.

However both files4ecr and files4cr work off of the E/CR number identifying all files associated with that E/CR number, irrespective of any other tags that they might have. So the files4cr in the above scenario would pick up all 11 files!

Now according to CVS a commit command should not commit files that have not been modified. The question is what does CVS use to determine that a file has been modified? Contents modified or just say date/timestamp modified? It appears that it's content modified

Still this makes files4[e]cr not very efficient. For example, CR #542 consists of ~3200 files that were modified. Since the last dev build 17 more files were modified. But files4cr picks up ~3200 files! If we are to transfer these over to GD then commit that seems like a large waste of effort

Posted by at 2:10 PM | Permalink