Issue: Unable to execute a partial revert on a change that is reworked later in the plan.

[tprocter]

It seems that under certain circumstances, the revert command executes the wrong revert script.

If you're reverting from a point between a change and a rework of that change, it doesn't acknowledge that that change has been reworked. The effect of that is that it runs the revert/change.sql file instead of revert/change.sql@tag.

I took a first stab at fixing this. I looks like the Engine::_load_changes sub needs to take changes into account outside of the immediate change list. My approach doesn't work though. Someone with better knowledge of the internals might have better luck.

Here's my attempt:

@@ -823,10 +823,10 @@
             App::Sqitch::Plan::Tag->new(name => $_, plan => $plan, change => $c )
         ) for map { s/^@//; $_ } @{ $tags };

@@ -823,10 +823,10 @@
             App::Sqitch::Plan::Tag->new(name => $_, plan => $plan, change => $c )
         ) for map { s/^@//; $_ } @{ $tags };

-        if ( defined ( my $idx = $seen{ $params->{name} } ) ) {
+        if ( defined ( my $idx = $plan->first_index_of($params->{name}, $c->id() ) ) ) {
             # It's reworked; add rework tags in reverse order by change.
-            my $dupe = $changes[$idx];
-            $dupe->add_rework_tags(map { $changes[$_]->tags } reverse $idx..$#changes);
+            #my $dupe = $changes[$#changes];
+            $c->add_rework_tags(grep { $plan->get($_) && $plan->get($_)->tags } reverse $#changes..$idx);
         }

         push @changes => $c;

[theory]

I think 1a4d6c3 should fix the issue. Would you mind taking it for a spin, @tprocter?

[tprocter]

Indeed. This solves the cases that I was having issue with. Thanks @theory!