If I enable tag_history after uploading images and tagging them, the current tags are not included in the log. This means if the site is vandalized or a mistake made while changing tags, the original tags will be unrecoverable because the first entry in the log is the change made after tag_history was enabled.
I propose that the current image_tags table be imported into the tag_histories table during the install process for the tag_history extension. Any idea of what kind of CPU impact this might have on a site with a large existing library?
I'm not sure automatically generating a tag history for all images in the install process is a good idea. It looks to me like (and I could be wrong) the install process is run on the first page load after the extension is enabled. That would mean, unless you took the server offline to do this, who ever managed to make the very next page request would be sitting there waiting for a massive database operation to finish.
A more efficient way to do this would be: if an image with no history is edited, generate a preceding history entry with the old tags as well as the entry containing the new tags. That way any changes made to images with no history now have something to revert to. And you save yourself the headache of processing the entire database at once.
That definitely sounds better than dealing with the whole database at once.
The other option that occurred to me was rewriting tag_history to store the previous tags during edit. Doing so makes it more confusing to associate who owns the current tags though (extra SQL required).