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
