On Tuesday 28 June 2011 03:13 PM, Stefan Sperling wrote:
On Tue, Jun 28, 2011 at 08:43:40AM -0000, ar...@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
Log:
Added a branch readme.
* BRANCH-README : New file.
Added:
subversion/branches/svn-bisect/BRANCH-README
Hi Arwin,
+SPEC
+====
+
+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.
Thank's for bringing this up.. I actually considered 1 and 3. Completely
overlooked 2.
About 1: In the non-interactive (script driven) bisection, the script is
free to
do anything (make local mods), because, some revisions may not compile
without
some local mods that have no connection to the bug that we're finding.
So we should
also allow the user to run bisect WITH local mods. Since having local
mods might result
in conflicts, this should be a caveat that the user should be warned of.
About 2 and 3: We must definitely ensure that the target is not a mixed
revision working copy,
and doesn't contain any switched subtrees, because, we need to be able
to restore to this
state upon "svn bisect reset", and I don't think we have any mechanisms
in place to keep track
of which nodes are at which revisions in a mixed revision wc, and
which subtrees are switched etc.
+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.
Will do this.. I'm looking for a good way to present this (searching
for some precedent).
+
+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
+things.
It's a good idea to stick to these values if git also uses them.
Sure. git bisect does make use of these codes. So I think we'll stick.
Regards,
Arwin Arni
