Stefan Sperling wrote on Tue, Jun 28, 2011 at 13:45:11 +0200:
> On Tue, Jun 28, 2011 at 03:36:32PM +0530, Arwin Arni wrote:
> > On Tuesday 28 June 2011 03:13 PM, Stefan Sperling wrote:
> > > 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.
>
> Will you require the script to reapply any local mods for each run?
> If so, this implies that you run revert at the start of each run
> (probably best to do before the update).
>
> Or are you planning on leaving any local mods in place?
> I don't think that is a good idea because sorting out conflicts
> can be a huge mess, especially with tree conflicts.
> Only the script can know which local changes apply cleanly to
> which revision.
>
Agreed that conflicts are an issue; but we can certainly say "We attempt
to apply <this> patch; if it fails, then we bail out and let the user
sort it out".
We could even extend things a bit and pass some parameters to the
bisection script telling it whether or not we applied local mods for it.
(the script can then do 'if argv[1] != "yes"; system.exit(128); fi' to
fall back to the "bail out to user" behaviour)
And of course we should check if hg/git/* have some established way
of passing such information to the bisection scripts...
> Speaking of tree conflicts, what if the node that is the root of the WC
> was moved in a revision that is included in the range being bisected?
> A simple update won't do in that case.
> You'll need to figure out the old and new URL before you update
> to a new revision, and perform aswitch from/to the old/new URL
> instead of an update incase the URLs don't match.
>
> > 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.
>
> Yes. My point is that it's not currently clear where responsibility
> lies. I.e. whether you should make svn bisect --start error out if
> the WC is mixed-rev, or whether it should simply run an update.
> Or maybe bisect --run always runs an update, so bisect --start
> doesn't need to care about this.
>
> It will be hard to automatically get rid of switched subtrees.
> Maybe the root is switched and some children were switched back
> to the URL we're bisecting. So I would suggest to make bisect --start
> error out in this case. Maybe all the other bisect commands should keep
> checking for switched subtrees as well (it's a cheap DB query).
>
> > Will do this.. I'm looking for a good way to present this (searching
> > for some precedent).
>
> See notes/http-and-webdav/http-protocol-v2.txt
Received on 2011-06-28 18:06:05 CEST