Instead of using an empty file "noext" to detect if an addon is installed with or without extarnals just assume all addons are installed with whatever the "No externals" setting is set at. When the user change the setting show a popup that he'll have to use "Reinstall addons" for the change to have full effect.
Instead of using an empty file "version-#####.#" to know what version an addon is at you could get that information by parsing the filename of Changelog-<Addon name>-r#####.txt or make a list and save it wherever JWU saves its settings.
The point is to not clutter the folder of the addon with files that's not actually from the addon.
You have to use another program (like Total Commander) or the command line interface (type cmd in the box you get from "Run..." on the start-menu. Then use mkdir with the path to the dir you want to make, ex: mkdir "C:\World of Warcraft\Interface\AddOns\BigWigs\.svn")
I think WAU "solves" this by also accepting "_svn" (underline instead of dot), not sure if JWU accept that as well.
Ill see what i can do about this one, but its not as "easy" as you think at first glance, because what about libraries if your using no-ext, if you revert back to a version that is "working" but its not compatible with the libs you have now (As they might have been updated/changed) your working addon would be broken as the old version isnt any longer compatible.
Personally i dont think addons are broken for long enough time for this feature to be worthwhile, but ill put it in the thinking box to see if i can come up with a smart solution to the problem with libs.
When using no-ext you can to revert the broken libraries just like any other addon (Usually old addons will still work with the new libs as long as there's no api-changes). Knowing what libraries that would need to be reverted could be a little hard. That's why I suggested that the XML-cleaner comment out tags instead of deleting them (But I understand that this would be a lot trickier than the way you do it now).
It's when running embedded that's the problem, you'd have to revert every addon using the library to prevent the new version from loading over the version in the reverted addon. Don't really see a workaround for this.
And also, just wanted to say that I don't in any way expect or demand you to implement this right away (or ever :P). Just wanted to get it out for discussion and see if you liked it or not :)
JWowUpdater is already the best updater available imo.
(No disrespect to WAU or WUU, but I like JWU better :))
Now that the updater is so solid I have a suggestion for a new feature if you need something to work on ;)
Since the SVN is for development stuff you sometimes get broken addons when updating to latest version.
My suggestion is a frame with all your installed addons (Like in "Delete an Addon"), where you can tick broken addons and specify a date (and time?) for each addon ticked.
When updating it will download the latest version older than the date specified. Changlog summary could show the reverted changes (with redish background) if it's not too much of a hassle.
Some kind of reminder when there's another update on the reverted addons would probably be nice as well, so you don't forget about them.
Ideally the date and time would still be saved when you untick so you can just go in and tick again if the issue wasn't resolved without having to remember the "safe" date.
About the case of the addons dir.
The path used inside the WoW MPQ-files is "Interface\AddOns\". That is capital I in interface, capital A and O in addons. So that's the way it should be named.
Renaming the dir might give wow trouble finding it on a case-sensitive filesystem.
Hehe, I agree. But that's just how some addons are written. :P
Look at Prat for example:
All embeds.xml does is including "libs\includes.xml"
libs\includes.xml is a list of Script-tags for all libs.
All modules.xml does is including "Prat_Modules\includes.xml"
Prat_Modules\includes.xml don't exist if you split Prat, otherwise it's a list of Script-tags for all Prat modules and also two included xml-files without any Include/Script-tags.