
The clusterpush.pl script allows you to run a cluster regression using
code that has not been committed to git. 

Usage:

  clusterpush.pl [product] ['bmpcmp'] ['lowres'|'hires'] ['32'] ['relaxtimeout'] [user]


Where product is one or more of gs, pcl, xps or mupdf or mujstest.
If you do not specify a product the product(s) tested will be cased on
what directory you are 'cd'ed to when the clusterpush.pl script is run.

bmpcmp indicates that a bitmap comparison of your output to that of the
last svn commit should be performed.

lowres or hires indicates to only perform a low-resolution or
high-resolution cluster run; by default both are performed.

32 indicates that the code is to be compiled in 32 bit mode (opposed
to the default of 64 bit)

relaxtimeout relaxes the timeout for each job, from 5 minutes to
30 minutes.  Note that the total time for the cluster job is still
limited to 2 hours.

user is your cluster user name, if you don't specify one, clusterpush.pl
uses, in order of preference, the value of one of the following
environment variables: CLUSTER_USER, USER, and USERNAME This works under
Linux, Mac OS X, Msys,  and probably cygwin.

The order of the options is not important but some of the options
are mutually exclusive (specifically 32 and relaxtimeout cannot both
be specfified).

You need to run clusterpush.pl from the top level directory (the same
directory from where you normally run 'make').  Clusterpush prints and
error if you try to run it from a different directory.

Results will be sent via email after the run is completed, which takes
about 30 minutes, presuming the cluster isn't busy.  Your code is compared
to the most recent baseline, so for meaningful results you will want
to sync your code with head if recent changes to head have resulted in
regression differences.

The first time you run clusterpush.pl it will take a really long time
to rsync your source to the master machine and then from the master to
the nodes.  After that things will go much quicker (unless, like me,
you accidently leave giant .ppm files in the current directory).

Futhermore the first time clusterpush.pl is run each cluster node has to
transfer your source tree from the cluster master; some of the nodes have
relatively slow internet connections and may time out.  The transfers
will complete, so the next time a clusterpush.pl is run everything will
proceed normally.

bmpcmp mode:

To use the feature run clusterpush.pl with the option bmpcmp (i.e.
"toolbin/localcluster/clusterpush.pl bmpcmp").  This will queue a job
that looks at the most recent none-bmpcmp clusterpush job you ran and
generates bitmaps of the differences for the first 1000 files listed
in the report.  It puts these files on the internets in the location
<http://www.ghostscript.com/~regression/$USER> and then sends you
an email telling you that it's done.  Since some of the test files
are customer confidential this directory is password protected, I've
emailed out passwords, contact me if you have misplaced your password.
BTW, I consider the fact that can look at output from other users, e.g.
<http://www.ghostscript.com/~regression/marcos>, a feature since this
allows users to refer to bmpcmp output in email and IRC disucssions
without having to email files around.

You can add bmpcmp to a normal clusterpush (i.e. 'clusterpush gs bmpcmp'
or 'clusterpush gs pcl xps ls bmpcmp').  This will queueu both jobs in
the correct sequence.

abort mode:

If you want to abort a queued or currently running cluster job you can
specify abort to the clusterpush.pl option: 'clusterpush.pl abort'.


