On Tue May 01 15:58:34 2007, particle wrote:
> > #####
> > [parrot] 502 $ ack --nohtml --nophp svn_entries
> > config/gen/revision.pm
> > 31: my $entries = $Parrot::Revision::svn_entries;
> >
> >
> your interpretation is correct. '.svn_entries' is an svn metadata file
> that's not even available in newer svn releases. Parrot::Revision
> should never have been mucking with svn internals, anyway, and should
> now be using the external api to get this info.
>
> this code should be ripped out.
> ~jerry
>
Okay, but we'll have to look at what to do with config/gen/revision.pm as well.
It contains
this code:
sub runstep {
my ( $self, $conf ) = @_;
my $revision = $Parrot::Revision::current;
my $entries = $Parrot::Revision::svn_entries;
$conf->data->set(
revision => $revision,
SVN_ENTRIES => $entries
);
...
Here is the output of 'ack' for SVN_ENTRIES in trunk (post-Configure.pl, in
this instance):
[parrot] 521 $ ack --nohtml --nophp SVN_ENTRIES
config/gen/revision.pm
35: SVN_ENTRIES => $entries
config_lib.pasm
274: set P0["SVN_ENTRIES"], P1
lib/Parrot/Config/Generated.pm
30: 'SVN_ENTRIES' => undef,
The 'undef' value for key 'SVN_ENTRIES' in the configuration hash is, now, not
at all surprising
and will simply go away when we eliminate the offending code from
lib/Parrot/Revision.pm.
But do we have to do anything with config_lib.pasm? (I've never patched any
.pasm files).
Thanks.
kid51
