Oh, there's an IRC channel? I wouldn't mind joining that and discussing this further.
Here's basically how I've handled this spin-off/port: every so often, I'll synch to the SVN. Whatever works for me, I keep. Whatever doesn't work, I have to wrap around a preprocessor instruction, like #define ANDROID, and redo. I know that there are some general coding guidelines, but I did not know if this was the appropriate way to handle the situation. My life would be much easier if the preprocessing work could be submitted directly to the trunk code, since I wouldn't have to diff so many times with so many false positives (i.e., diffing against actual new content, and diffing only to discover that my preprocessor instructions caused a mismatch). Edit: also, none of the Wii configuration works either. No idea how hard it would be--I know you can pair Android to a Wiimote, but I've never tested it myself.
As well, I have my own GitHub account, I know how to use git better, so I feel more comfortable putting it there. But in a better world it would be added as its own "flavor."
Put the contents of the data directory into a data-x.y.z.zip and install it as neverball/data/data-x.y.z.zip?
That's more or less how I've done it. Reading the Android data files is tricky, since it's a zip within a zip--so I'm trying to modify the PhysicsFS code as gently as possible. Previously, it was just a simple matter of making the data directory the sd card--no muss, no fuss. Now, I'm thinking I have to prepend the path to the data zip before any fs_open() call. That doesn't sound very efficient, though.