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.
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 13:45:52 CEST