bk bisect command runs on a copy of the current repository in
<repo>/BitKeeper/tmp/bisect. The reason for that is so bk can rollback to an older revision and be sure it still has the data to roll forward. And it removes most problems with local work or extra files in the repository.
This causes some people problems because a fresh clone of the repository will require a full rebuild of the repository which can be very slow. Even if the following builds in the bisect directory will be incremental. So they want bisect to run in the current repository.
I propose to add a
--inplace option to bisect that will skip the initial clone to the tmp directory and will instead run in place. For this to be safe the code needs to be able to restore any csets removed. It could require that the local repo be a strict subset of the default parent, or it could still do the clone to
BitKeeper/tmp/bisect and use that as the source for any csets to pull back in. Or perhaps we have an extra option to point at a local repository to use as a backup.
Other sanity checks I may want to run:
- No locally modify files or files with pending deltas
- No extra files that are not ignored
These might be intentional and could be OK if the region being checked doesn’t conflict with these and we recover from a failed pull or undo well. But banning these could reduce user errors.
--inplace and bisect completes successfully should the local repository the repository be restored to tip or left at the oldest cset that reproduces the problem. The problem with not restoring the tip is that we have to keep the
BitKeeper/tmp/bisect data and the user might not know where to find it.
@martindorey, thoughts on what semantics you guys would want?
A related request would be an interactive mode for bisect rather than requiring a script to evaluate each cset, but I will create a new topic for this idea when I get around to it.