From: Bobby N. <bwn...@fe...> - 2004-08-10 15:19:42
|
Hello, I've noticed that the Log4Perl sources don't play well with CVS when using the keyword expansion feature. In particular, the Config.pm and Logger.pm files get hosed up if you check them out from a CVS repository as CVS expands the following lines to include the Log history for the file: 388572 Log4perl $ grep "\$Log.*\\$" Config.pm return $Log::Log4perl::VARS_SHARED_WITH_SAFE_COMPARTMENT{$args[0]}; $Log::Log4perl::VARS_SHARED_WITH_SAFE_COMPARTMENT{$args[0]} =3D $args[1]; return $Log::Log4perl::ALLOWED_CODE_OPS{$args[0]}; $Log::Log4perl::ALLOWED_CODE_OPS{$args[0]} =3D $args[1]; $Log::Log4perl::ALLOW_CODE_IN_CONFIG_FILE =3D $args[0]; 388572 Log4perl $=20 388572 Log4perl $ grep "\$Log.*\\$" Logger.pm=20 level =3D> \$Log::Log4perl::Level::L4P_TO_LD{\$level}, 388572 Log4perl $=20 This is more than a little annoying as we typically will check all external source code, such as Log4Perl, into our CVS server for tracking and inclusion in our projects. By default, those two files will get hosed up when we check them back out because CVS interprets the '\$Log.*\\$" as it's $Log$ keyword. The only workaround is to tag these as binary files in CVS, which works but is a bit of a kludge and it's easy to forget. Would you please change the above two files so that they no longer match the regular expression, "\$Log.*\\$"? This would really help out folks in the field. =20 Thanks, Bobby Nations Sr. System Architect FedEx Services P.S. Great product, BTW. I look forward to using it extensively. Thanks for all of your work :-) |