I'd say that these changesets should be reworked to group related changes into one commit, and carry better messages. Reading descriptions like 'and again' in 'hg blame' output is no fun and is a waste of time. Project log is important for maintenance, and I use that a lot, that's why I am so picky.
This was my first time with mercurial and I had a lot of grief getting this sorted up to the point I made the pull requests. Commits before that are due to said grief. I tried the histedit tool but it complains it cannot edit history that contains merges. Possibly it'd be better to create a new fork and copy the files across to that.
Oh yes. Pull requests, queues, merging, rebasing and editing history right from the start. Not bad for a first try. People usually give up earlier, so I am sure you can do this. =)
With those merges I'd probably start from new clone too, then copy files over and use 'hg record' to split changes into several commits. When it is not possible, I save a copy of a file, remove extra features manually, commit, restore copy, and repeat the process until all features are split.
Hi Tom; the changes you have here look fine. (Not sure why the sys.stdout wrappers are needed though?) It does seem like a lot of fiddly commits though. If you want to PM me via google chat we can probably fix things up. Anatoly's suggestion of starting from clean and copying things over (maybe just with diff and patch, or file copies as he suggests) will probably be the simplest way. In fact the whole thing looks like it could be one commit to me (maybe the sys.stdout wrappers are a separate one).
Sorry about this being complicated -- I'm guessing you're more of a git user.
Changing the sys.stdout back to the original sys.stdout makes any stdout intercepts get removed if you get an error that drops out of the build, and appear to go some way to alleviating the 'scons had an error but I got no output' issues.
I'll try to produce a new forks with the appropriate changes in a slightly more sane fashion