On 8 Feb 2014, at 0:14, Matt Neuburg wrote:
[…] it's the disabling. You were right: these _are_ deltas. But the only change I made is to disable the bundles. So disabling a bundle creates a delta.
Ah, right. I read your previous reply as “uninstall”. Disabling a managed bundle (or bundle item) will create a delta.
That seems a strange thing for TM2 to do […]
Basically Preferences → Bundles will install/uninstall into Managed and nowhere else, and it will keep bundles in Managed up-to-date and no-one is ever allowed to edit these bundles in place, as they should be an exact copy of what’s upstream.
If you go into the bundle editor and make an edit, any edit, it will be written to ~/Library/Application Support/Avian/Bundles. Editing something that has been installed into that location will edit it in place, but anything installed outside that location will cause a delta to be written there, detailing what has been changed compared to the master copy.
Since bundles are sort of a distributed database, disabling a single item simply sets ‘disabled = true’ in the property list for that item, same for a bundle (here the item is the info.plist in the root of the bundle).
So at least from an implementation POV the behavior you see makes sense, and it means that deleting ~/Library/Application Support/Avian/Bundles will “remove local customizations” incl. undeleting or enabling potentially deleted or disabled default items.