On Tuesday 28 June 2011 05:15 PM, Stefan Sperling wrote:
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.
Whoa! Didn't think of this at all. Will keep this in mind.
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).
Considering all these points,it should work this way:
svn bisect --start -rN:M
check for mixed rev, switched subtrees and local mods and error out if
it is.
Initialize the bisect env.
svn bisect --run script
--->run checks again.
^ update to target rev.
| run script / let user run svn bisect good, bad or skip
| based on exit code choose good, bad or skip.
<---calculate new target rev.
This way, the script is responsible for applying any local mods and
reverting them before exiting.
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
Thanks for the pointer.
Regards,
Arwin Arni
