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
Received on 2011-06-28 14:37:38 CEST