Commit first, review later.
The change is basically new project files, which don't even overwrite old stuff. It's a safe change.
Besides, code is easier to review once it's in the SVN, and if further changes are needed, or something needs to be undone, it can be documented in a commit message why the change is needed.
It's not a big deal to break what's in the SVN. In some organizations, with more developers, and a more rapid development cycle, you probably want to avoid breaking trunk since that affects other active developers, and with frequent commits, other people will have more difficulty knowing when the problem was introduced. Here we just don't have that problem.
Some review systems basically have an extra repository that you push changes to, and only once they are reviewed and accepted is that change pushed to the main repository that everyone clones from. That's overkill for us. It's also more process heavy than it needs to be. Our needs are simpler. Just break stuff, learn from it, and try again. We have only one repository, and generally just work from trunk, not on separate branches.
Thank you for dealing with this. I just checked out the package, and the older version too. The changes look quite straightforward.