On Tuesday 21 June 2011 02:05 PM, Julian Foad wrote:
Here's one I wrote a few months back. I didn't send it here because I
didn't think it was a serious proposition, just something fun to
exercise my brain cells. :-)
One thing "git bisect" does that's not implemented here is to support a
third response, "unable to test", and skip such revisions. I tried
thinking about an algorithm to do that nicely, but didn't get anywhere
really concrete.
- Julian
Stefan Sperling wrote:
On Tue, Jun 21, 2011 at 01:15:06PM +0530, Arwin Arni wrote:
Hi All,
I am currently trying to implement "svn bisect" subcommand. Yes, I
know there are some good scripts out there that work, but it's not
part of our API. I figured this would be a decent addition to our
code. Here are a few things I wanted to ask the community:
1. Would it be better if the command ran as a single process
throughout the bisect operation and keep track of things in memory,
or should it work like the scripts that are out there which keep
track of things on disk (in a persistent file)?
Depends on your requirements. I suppose bisect is supposed to
be restartable? If so it would probably make sense to stick
state somewhere into wc.db?
2. For the scripts that are currently out there, the 'probe script'
runs in the environment in which the bisect script was run. Is it
safe to have a subcommand that runs an external script? Is there a
precedent to this kind of behaviour?
The script could delete files, trash the working copy, whatever.
But it is, after all, supplied by the user doing the bisection, right?
So I don't think there is any difference here to existing mechanisms
that invoke diff commands and the like. Those are equally "unsafe".
3. Will this feature be considered at all (if it is any good) or am
I simply doing something to exercise my brain cells?
I would consider it useful.
Since you have some track record in getting patches committed,
I'd like to offer you commit access to a branch in our repository
so you work on this there if you like.
I'd really appreciate that. Thanks for the support.
Very nice. Julian's patch is a few steps ahead of where I am right now.
I'll gladly work on the "tristate" of the probe-script-outcome (The
unable-to-test situation).
I'm assuming that we make a spec for the probe script as follows:
Good Revision - return 0
Bad revision - return 1
Some other internal error (unable to test) - return 2
And if we're unable to run the script itself for some reason, we
recognize that as "return value 2"
Regards,
Arwin Arni
