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
Received on 2011-06-21 10:57:09 CEST