Minor fix for patchlets which modify multiple projects
PATCH 1/1 Minor fix for patchlets which modify multiple projects
While converting a match of mine to pom-ng, I noticed that apply_patchlet doesn't properly determine the list of projects which are affected by the patchlet. In my case, the patch would be incompletely applied - the kernel space part would apply, but the userspace part would not. The following patch (agains pom-ng cvs) should fix this. -Brad Fisher
Index: Netfilter_POM.pm
===================================================================
RCS file: /cvspublic/patch-o-matic-ng/Netfilter_POM.pm,v retrieving revision 1.26
Netfilter_POM.pm 12 May 2004 19:02:22 -0000 renamed from Netfilter_POM.pm 11 May 2004 13:53:13 -0000 1.26 +2 -3
@@ -852,9 +852,11 @@ my(@projects); # print Dumper($patchlet); - @projects = keys %{{ keys %{$patchlet->{files}}, - keys %{$patchlet->{patch}}, - keys %{$patchlet->{ladds}} }}; + my %projects = ( ); + foreach my $p ( keys %{$patchlet->{files}}, keys
%{$patchlet->{patch}}, keys %{$patchlet->{ladds}}) {
+ $projects{$p} = 1;
+ }
+ @projects = keys %projects;
foreach my $proj (@projects) {
return 0 unless ($self->apply_newfiles($patchlet, $proj,$revert, $test, $copy)
Quoted 7 lines · Brad Fisher
While converting a match of mine to pom-ng, I noticed that
apply_patchletdoesn't properly determine the list of projects which are affected by the patchlet. In my case, the patch would be incompletely applied - the kernel space part would apply, but the userspace part would not. The following patch (agains pom-ng cvs) should fix this. -Brad Fisher
Thanks Brad, I've applied a small variation of this, because I don't know if perl will complain about two equally named variables (@projects and %projects) with warnings turned on.
Regards
Patrick
Index: Netfilter_POM.pm
===================================================================
RCS file: /cvsroot/patch-o-matic-ng/Netfilter_POM.pm,v retrieving revision 1.26
Netfilter_POM.pm +5 -3
@@ -852,9 +852,11 @@ my(@projects); # print Dumper($patchlet); - @projects = keys %{{ keys %{$patchlet->{files}}, - keys %{$patchlet->{patch}}, - keys %{$patchlet->{ladds}} }}; + foreach my $p ( keys %{$patchlet->{files}}, + keys %{$patchlet->{patch}}, + keys %{$patchlet->{ladds}} ) { + push @projects, $p; + } foreach my $proj (@projects) { return 0 unless ($self->apply_newfiles($patchlet, $proj, $revert, $test, $copy)
Quoted 3 lines · Patrick McHardy
Thanks Brad, I've applied a small variation of this, because I don't know if perl will complain about two equally named variables (@projects and %projects) with warnings turned on.
I don't think your patch is quite right. You can end up having the same project listed multiple times with your patch, which is why I used the separate hash - key collisions are reduced to single entries. I guess as long as it is no problem for a project to be processed multiple times, then your patch will be OK, but if that isn't the case, you may want to look into it again.
As far as variables with the same name and different types, I don't believe Perl complains. I typically program with 'use strict', which I believe enables all warnings, and have used naming like this before. Of course it does add quite a bit of ambiguity, so renaming the %projects hash would probably be a good idea if you choose to use a variation of my patch.
Quoted 2 lines
Regards
Patrick
-Brad
Quoted 5 lines · Brad Fisher
I don't think your patch is quite right. You can end up having the same project listed multiple times with your patch, which is why I used the separate hash - key collisions are reduced to single entries. I guess as long as it is no problem for a project to be processed multiple times, then your patch will be OK, but if that isn't the case, you may want to look into it again.
You're right, I just experienced that problem with the raw table patch. Applying your original patch now, thanks.
Regards
Patrick
Hi Brad,
Quoted 30 lines · Brad Fisher
While converting a match of mine to pom-ng, I noticed that
apply_patchletdoesn't properly determine the list of projects which are affected by the patchlet. In my case, the patch would be incompletely applied - the kernel space part would apply, but the userspace part would not. The following patch (agains pom-ng cvs) should fix this. -Brad FisherIndex: Netfilter_POM.pm
===================================================================
RCS file: /cvspublic/patch-o-matic-ng/Netfilter_POM.pm,v retrieving revision 1.26
diff -u -r1.26 Netfilter_POM.pmNetfilter_POM.pm 12 May 2004 19:02:22 -0000 renamed from Netfilter_POM.pm 11 May 2004 13:53:13 -0000 1.26 +5
-3@@ -852,9 +852,11 @@ my(@projects); # print Dumper($patchlet); - @projects = keys %{{ keys %{$patchlet->{files}}, - keys %{$patchlet->{patch}}, - keys %{$patchlet->{ladds}} }}; + my %projects = ( ); + foreach my $p ( keys %{$patchlet->{files}}, keys %{$patchlet->{patch}}, keys %{$patchlet->{ladds}}) { + $projects{$p} = 1; + } + @projects = keys %projects; foreach my $proj (@projects) {return 0 unless ($self->apply_newfiles($patchlet, $proj,
Quoted 1 line
$revert, $test, $copy)
Yes, that was a bug. My code should have written as
@projects = keys %{{ %{$patchlet->{files}},
%{$patchlet->{patch}},
%{$patchlet->{ladds}} }};Thank you the fix.
Best regards,
Jozsef
-
E-mail : [email protected], [email protected] PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary