This command specifies the earliest revision that PinDown should examine when debugging failures.

This is used to specify a debug window, i.e. how far back in time that PinDown should debug failures.

In theory it is not necessary to use this command if the test has passed at some point in history, but that is not always the case for all tests and builds. Also for stability, in case the flow is broken and passes are not possible to reproduce, you don’t want PinDown to search backwards forever. Also when running random tests, then each seed is a new scenario which may never have passed.

Default the earliest revision limit is set to the revision 4 weeks ago compared to the latest revision.

This command affects performance. The shorter the debug window the fewer revisions to check. However as PinDown is using a parallel binary search algorithm this does not have a major effect on performance.

Other performance related PinDown commands are set_debug_bandwidth, set_max_tests, set_diagnose_multipletests and set_diagnosis_optimization.

Syntax

set_earliest_revision "none";
set_earliest_revision "hardlimit";
set_earliest_revision "repository";
set_earliest_revision [-repository "repository"] -revision "revision" | -weeks "weeks" | -days "days" | -hours "hours";

"none"

Remove the default earliest revision limit from all repositories.

"repository"

Remove the default earliest revision limit from the specified "repository".

"hardlimit"

Don’t go beyond the defined time limit (defined by -weeks, -days, -hours) even if there is a known good run further back, because debugging that far back takes too much time.

‑repository

If specified sets the limit on this repository, else all repositories gets the same limit.

‑revision

The revision that the limit should be set to. Use "HEAD" to set it to the repository head revision. "HEAD-n" can be used to set the limit n revisions before HEAD. PREVIOUSHEAD can be used to specify the previous run.

‑weeks

The number of weeks back the limit should be set to.

‑days

The number of days back the limit should be set to.

‑hours

The number of hours back the limit should be set to.

Examples

Example 1

Clear earliest revision limit on all repositories

set_earliest_revision "none"; // Clear all earliest revisions

Example 2

Clear earliest revision limit only on the repository "testbed1"

set_repository -type "svn" -location "http://localhost/svn/testbed0" -checkoutarea "tb0";
set_repository -type "svn" -location "http://localhost/svn/testbed1" -checkoutarea "tb1";
set_earliest_revision "http://localhost/svn/testbed1";

Example 3

Set earliest revision to 2 weeks back on all repositories

set_earliest_revision -weeks "2";

Example 4

Set earliest revision to 4 days back on all repositories

set_earliest_revision -days "4";

Example 5

Set earliest revision to 12 hours back on all repositories

set_earliest_revision -hours "12";

Example 6

Set earliest revision to 1234 on all repositories

set_earliest_revision -revision "1234";

Example 7

Set earliest revision to 1234 for testbed0

set_earliest_revision -repository "http://localhost/svn/testbed0" -revision "1234";

Example 8

Set earliest revision to repository head

set_earliest_revision -revision "HEAD";

Example 9

Set earliest revision to limit timeline to the latest 11 revisions.

set_earliest_revision -revision "HEAD-10";

Example 10

Set earliest revision to limit timeline to the previous head revision.

set_earliest_revision -revision "PREVIOUSHEAD";

Example 11

Set earliest revision to limit timeline to 10 revisions before the the previous head revision.

set_earliest_revision -revision "PREVIOUSHEAD-10";

Example 12

Set earliest revision to limit timeline to the head revisions 2 runs ago.

set_earliest_revision -revision "PREVIOUSHEAD{2}";

Example 13

Set earliest revision to limit timeline to 10 revisions before the head revisions 2 runs ago.

set_earliest_revision -revision "PREVIOUSHEAD{2}-10";

Example 14

This is the same example as in example 4 above. However now we are also telling PinDown to not venture out beyond the specified 4 day time limit even if it is aware of a good run further back in history. The reason for using hardlimit is that the known good run may be too far back in time and it takes too long time to sort out all the issues that have occurred since that point. It is basically a performance issue that is solved by specifying a hard limit.

set_earliest_revision -days "hardlimit";
set_earliest_revision -days "4";