[Webkit-unassigned] [Bug 23343] Documentation for bisect-builds would be useful

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=23343


ddkilzer at webkit.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrowe at apple.com,
                   |                            |aroben at apple.com,
                   |                            |ddkilzer at webkit.org




------- Comment #1 from ddkilzer at webkit.org  2009-03-17 09:00 PDT -------
Please be more specific about what isn't clear about the command-line help:

$ ./WebKitTools/Scripts/bisect-builds --help
Search WebKit nightly builds for changes in behavior.
Usage: bisect-builds [options] [url]
  [-b|--branch name]             name of the nightly build branch (default:
trunk)
  [-d|--download-directory dir]  nightly build download directory (default:
~/Library/Caches/WebKit-Nightlies)
  [-h|--help]                    show this help message
  [-l|--local]                   only use local (already downloaded) nightlies
  [-p|--progression]             searching for a progression, not a regression
  [-r|--revision M[:N]]          specify starting (and optional ending)
revisions to search
  [--safari-path path]           path to Safari application bundle (default:
/Applications/Safari.app)
  [-s|--sanity-check]            verify both starting and ending revisions
before bisecting

-b|--branch was only useful when there were separate nightly builds for SVG and
non-SVG.  Could probably be obsoleted.

-d|--download-directory is if you don't want the copies of nightly builds
stored in the default location (or if you already have some downloaded).

-l|--local is for when you're not connected to the Internet (or your disk is
full), so you only want to search the local copies of nightlies that are
already downloaded.

-p|--progression is used if you're searching for a progression (instead of a
regression).  It basically makes it much less confusing when answering the
question, "Did the bug reproduce in rNNNNN (yes/no/broken)?", because you don't
have to reverse your logic.  (A regression assumes that the older revision will
NOT reproduce the bug and that the newer revision WILL reproduce the bug.  A
progression is the opposite.)  The script assumes a regression by default
unless this flag is used.

-r|--revision lets you specify which revisions to test.  You can use various
forms:

* No revisions means to test every revision available.  (Note that Safari 2.0.x
is able to test the most nightly builds; newer versions of Safari are able to
test fewer and fewer nightly builds.)
* Specifying one revision gives a lower bound (the lowest revision to test). 
The upper bound is the most recently nightly build.
* Specifying two revisions gives a lower and an upper bound.  Note that two
revisions may be specified as "-rNLOWER -rNUPPER" or "-r NLOWER:NUPPER".

--safari-path is useful if you've kept older Safari binaries around and want to
use them to test.

-s|--sanity-check tells bisect-builds to check both the lower and upper bound
revisions to make sure that the bug does (or does not) reproduce in those
revisions (so you don't start bisecting under false pretenses).


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.