On Tue, Jun 28, 2011 at 08:43:40AM -0000, arwin_at_apache.org wrote:
> Author: arwin
> Date: Tue Jun 28 08:43:40 2011
> New Revision: 1140482
> URL: http://svn.apache.org/viewvc?rev=1140482&view=rev
> Added a branch readme.
> * BRANCH-README : New file.
> +svn bisect start [-rN[:M]]
> +Initialize the bisection state.
> +If a state already exists, clean it up and create a fresh one.
> +If a revision range is specified, limit bisection to this range.
> +If a single revision is specified, bisect from that revision to HEAD.
> +If no revision is specified, bisect from revision 1 to HEAD.
Do you think it would be a good idea to also check the following
in bisect start:
1) the working copy has no local mods
2) the working copy has no switched subtrees
3) the working copy is at a uniform revision
These are also enforced by merge --reintegrate.
I think 1 and 2 are very important for a clean bisection.
The third one is not really necessary if svn bisect run will always
run an update first.
> +svn bisect run [my_script [args]]
> +Start the bisection. If no script is given, start the bisect in
> +interactive mode. i.e after updating to a specific revision, wait
> +for the user to manually run tests and mark the revision as good,
> +bad or skip.
So as I understand your implementation in-progress will first feature
the 'interactive' mode, and then later the script mode?
Maybe you could add some milestone defintions to show how you
are planning to progress. Having clear milestones would also allow
us to determine when bisect is "good enough" and can be reintegrated.
> +The script should follow the following spec:
> +Good revision : Exit Code 0
> +Bad revision : Exit Code 1 thru 127 (except 125)
> +Skip revision : Exit Code 125
> +Abort bisection : Any other Exit Code
> +The above mentioned exit codes conform to the way git bisect does
It's a good idea to stick to these values if git also uses them.
Received on 2011-06-28 11:44:53 CEST