Pull requests

#76 Declined
Repository
thosrtanner/SCons - TRT fork SCons - TRT fork
Branch
default
Repository
scons/SCons SCons
Branch
default

readonly cache, small improvements to command line

Author
  1. Tom Tanner
Reviewers
Description

1) Add --cache-readonly option to allow use of cache without updating

2) Allow multiple --debug options to be specified at one (--debug=option1,option2)

3) Some improvements to the way errors are handled, to try and stop the output being eaten. Also producing some output when there's no nodes to build

4) If timing information is requested, don't lose error information

Comments (6)

  1. anatoly techtonik

    https://bitbucket.org/scons/scons/pull-request/76/readonly-cache-small-improvements-to/commits

    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.

    http://mercurial.selenic.com/wiki/HisteditExtension http://mercurial.selenic.com/wiki/EditingHistory

  2. Tom Tanner author

    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.

  3. anatoly techtonik

    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.

  4. Gary Oberbrunner

    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.

  5. Tom Tanner author

    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