rebaseline_server: add actual_repo and actual_revision command line options

rebaseline_server: add actual_repo and actual_revision command line options

So, if you want to see divergences from expectations as of https://code.google.com/p/skia-autogen/source/detail?r=29365 , specify --actuals-revision 29365

This is also handy for testing rebaseline_server performance improvements against a static set of results.

BUG=skia:2248
NOTREECHECKS=True
NOTRY=True

Committed: http://code.google.com/p/skia/source/detail?r=13726

[epoger, 2014-03-10 17:38:14]

Ready for review at patchset 1.
First LG wins.

[borenet, 2014-03-10 18:01:12]

Nice!  This will allow me to rebaseline flaky GMs even when they didn't fail in
the last run.  LGTM assuming "svn update . --revision HEAD" is valid.

https://codereview.chromium.org/193023002/diff/1/tools/svn.py
File tools/svn.py (right):

https://codereview.chromium.org/193023002/diff/1/tools/svn.py#newcode106
tools/svn.py:106: return self._RunCommand([SVN, 'update', path, '--revision',
revision])
Does "--revision HEAD" do the right thing?  Or should we just leave off the
--revision parameter when revision == HEAD ?

[epoger, 2014-03-10 18:08:54]

https://codereview.chromium.org/193023002/diff/1/gm/rebaseline_server/server.py
File gm/rebaseline_server/server.py (right):

https://codereview.chromium.org/193023002/diff/1/gm/rebaseline_server/server....
gm/rebaseline_server/server.py:550: 'Defaults to %(default)s .  Beware of
setting this '
On 2014/03/10 18:01:12, borenet wrote:
> Nice!  This will allow me to rebaseline flaky GMs even when they didn't fail
in
> the last run. 

I *think* that will work, but as noted in the warning here, rebaselining against
old actuals requires caution.

https://codereview.chromium.org/193023002/diff/1/tools/svn.py
File tools/svn.py (right):

https://codereview.chromium.org/193023002/diff/1/tools/svn.py#newcode106
tools/svn.py:106: return self._RunCommand([SVN, 'update', path, '--revision',
revision])
On 2014/03/10 18:01:12, borenet wrote:
> Does "--revision HEAD" do the right thing?  Or should we just leave off the
> --revision parameter when revision == HEAD ?

Yup, it works fine.  From "svn help update":
  -r [--revision] ARG      : ARG (some commands also take ARG1:ARG2 range)
                             A revision argument can be one of:
                                NUMBER       revision number
                                '{' DATE '}' revision at start of the date
                                'HEAD'       latest in repository
                                'BASE'       base rev of item's working copy
                                'COMMITTED'  last commit at or before BASE
                                'PREV'       revision just before COMMITTED

... and I tested it, to make sure.

[epoger, 2014-03-10 18:09:12]

The CQ bit was checked by epoger@google.com

[commit-bot: I haz the power, 2014-03-10 18:09:21]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/epoger@google.com/193023002/1

[commit-bot: I haz the power, 2014-03-10 18:09:28]

Change committed as 13726