[Bug 5530] New: Allow bisect to accept a filtering revset

[mercurial-bugs at mercurial-scm.org]

https://bz.mercurial-scm.org/show_bug.cgi?id=5530

            Bug ID: 5530
           Summary: Allow bisect to accept a filtering revset
           Product: Mercurial
           Version: default branch
          Hardware: PC
                OS: Windows
            Status: UNCONFIRMED
          Severity: feature
          Priority: wish
         Component: Mercurial
          Assignee: bugzilla at mercurial-scm.org
          Reporter: matt_harbison at yahoo.com
                CC: mercurial-devel at mercurial-scm.org

In a large monolithic repository of many components, not every changeset
applies to the component being bisected.  It would be nice to be able to
specify a subset of the full range, for example with 'file(..)'.  Consider an
exaggerated case where the range is a linear 100..200, but only {100, 200} are
relevant.  That's ~6 uselessly duplicated tests.  Even if you recognize that
the test for a given changeset is redundant, skipping only moves to the next
commit instead of cutting the range in half.

A hack is to use a shell script as the command that automates the skips, and
prompts for good/bad:

filter=... # revset

match=$(hg log -r $HG_NODE -T "{ifcontains(rev, revset(\"${filter}\"), 'y')}")

if [[ $match != 'y' ]]; then
    # Filtered out: skip
    exit 125
fi

# prompt for good/bad/skip

The problems are the small movement for each skip, it won't work on Windows
without MSYS, and also a full checkout is done for each irrelevant version.  I
tried using --noupdate, and then updating in the script once past the skip
check. But the script must be getting called while a lock is held, as it
deadlocks.

Is this something that narrow clone also needs, or is this a case of just
saving the revset in the bisect state and applying it?

-- 
You are receiving this mail because:
You are on the CC list for the bug.