The check for rolling back the pbversion0000000000001 tag wouldn't log any
errors because it was after the return 0 statement.
If a set of assets that were programmatically generated were rolled
back, and the assets had a parent child relationship then there's
a race condition that could cause the parent to be purged before
child. Since purging the parent _also_ purges the child, the system
would try to purge the child twice and this causes a fatal error.
Programmatically generating the assets causes their revisionDates
to be the same, and that causes the return order of the assets to
be uncertain.
The solution is to generate the list of assets to be rolled back
by revisionDate _AND_ lineage. This guarantees that children are
purged first.
This bug was exposed in t/Macro/RootTitle.t However, the bug
seems to be system dependent since the revisionDate depends on how
fast the system can create assets.
