Tracking what Node Find Replace is doing

This is by design. Node find replace was created for making large changes and therefore talks to the db directly instead of using the node api.
Aside from the overhead that would be incurred using the node api, doing multiple undo/redos would result in multiple revisions which would cause the revision table to grow exponentially when doing a find/replace that affects every node. Las but not least, talking to the tables directly allows find replace in other things beside nodes such as filepaths, blocks etc.

To clarify the question above: I did a replace operation on node bodys which resulted in the message: "... node body revisions replaced". That implicated for me that something has been done with node revisions.

However, the project page currently says: "I didn't want find and replace operations to generate new revisions because this would bloat the node_revisions table quite a bit". Since I find this quite confusing (what does it change exactly?), this is most likely a request to update or clarify the documentation.

This basically boils down to the question: Is there a way for tracking what the "Node Find Replace" module has been doing on which nodes (e.g. some kind of logging, or a possibility to display the History of a "Node Find Replace" operation)?

Thanks & greetings, -asb

PS: The module is great, but a bit scary - I'm just learning to trust it ;-)

After running a find replace the find replace operation is added to watchdog.
The reason for adding the undo/redo functionality is partly to deal with the fact that no revisions are created, and the undo feature is much simpler than tracking revision numbers and reverting revisions for lots of nodes. Also, the undo/redo works with all find/replace operations not just nodes, and uses the same code / api.
node_find_replace_undo($hid)
node_find_replace_redo($hid)

It just replaces the current revision for the node. Well, it is scary when you think that you can use it to update every node, block, filepath etc. So it is good that scares you and you should always make a backup just in case something goes wrong. That said, I have used it for several projects and have never had a problem. I has litterally saved me countless hours.
The code is pretty straight forward and about all that could go wrong would be if somehow an update didn't take and the db schema was out of whack. In that case it could do a bunch of replaces without being able to create the undo info. As soon as I get some time I will write some unit test and maybe tweak it so undo info is saved before replace info.
The way undo/redo works is very simple. The schema for the history table just stores
hid,key1(name/value),key2(name/value),key3(name/value),table_name,field_name, find_string,replace_string
The table name and field name are used to store the field that is changing, and the key(name/values) are used to get a unique row so for node they would just be nid and the nid value
Several tables do not have unique keys, so that is why I allow up to 3 fields to come up with a unique row.
Then the value before and after the replace is stored so we can undo/redo as many times as we want and only the effected rows are effected.

The way undo redo works has some minor implications.
The find replace is not re-done or undone when doing undo / redo. If I did that than if you accidentally replaced every instance of A with B then then Apple would become Bpple. If the undo ran the replace in reverse then Boat would now become Aoat and any further undo / replace would just end up messing up more stuff.
So the undo redo puts things back to the value of old_string or new_string at the time of the replace for that effected row/table/field only.
This means that if you do a replace, wait a week and then do an undo you would loose any data that had changed for an effected field.
So basically it is just intended to fix things and the undo is just there in case you mess up. After you are happy with the replace you should delete the history for that replace.

I am glad you like the module.

I do not have it in there currently, but adding a full history view to see all the nodes effected would be very easy.