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 :-)
|
