[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 3304] New - svn-bisect

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 31 Oct 2008 16:28:40 +0200 (Jerusalem Standard Time)

Robert Millan wrote on Fri, 31 Oct 2008 at 15:05 +0100:
> On Fri, Oct 31, 2008 at 12:21:44AM +0200, Daniel Shahaf wrote:
> > Robert Millan wrote on Wed, 29 Oct 2008 at 20:38 +0100:
> > > AFAIK, last known-good revision + first known-bad revision is enough
> > > information to determine what to try next. At each interation (including
> > > the first one), these are specified either by the user ("svn-bisect bad xxx")
> > > or obtained from "svn info" output ("svn-bisect bad").
> > >
> >
> > ... and the user is supposed to implement (himself) a loop that calls
> > your script with the right argument?
>
> Yes. This is intentional; it is inspired by git-bisect which operates
> similarly:
>
> http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
>

See 'git-bisect run'.

> I think this is highly desireable as many people are already used to this
> procedure (and I think it's a reasonably good one anyway).
>

If you or others like to work that way, I won't stop you. But if all
the script does is save me from calculating (a+b)/2, then I don't see
any reason to use it...

Daniel

> A typical user session would be:
>
> svn-bisect start
> svn-bisect bad 4321 # mark 4321 as bad
> svn-bisect good 1234 # mark 1234 as good
> # svn-bisect picks a new revision and updates to it
> # user tests it
> svn-bisect bad # user determined it is bad
> # svn-bisect picks a new revision and updates to it
> etc
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-31 15:28:59 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.