[darcs-users] [patch106] resolve issue1208: trackdown --bisect (complete branch...

[Radoslav Dorcik]

Hello!

On Wed, Mar 31, 2010 at 9:48 PM, <mf-hcafe-15c311f0c at etc-network.de> wrote:

>
> On Wed, Mar 31, 2010 at 02:49:30PM -0400, Max Battcher wrote:> Eric Kow
> wrote:
> >> 1. What problem does the proposed feature solve?
> >>
> > The obvious question here, particularly in the pro-active case: if
> > --bisect is preferable in most/all cases (it should be faster in most
> > cases, right?), perhaps --bisect should be the default "trackdown" and
> > the current one renamed/deprecated?
> >
> > That is, what are the use cases where one would prefer existing
> > trackdown over trackdown --bisect?
>
> when i was still up to date what's going on with this patch, it wasn't
> possible to restrict the range of patches to search.  this can be a
> problem if the test script acts non-continously over the complete
> repository (i.e. used to work some time, then not work, then work
> again...).  in that case you'd want to either work the patch set
> linearly backwards to find the most recent point of change, or
> restrict the search space to a fraction of the repository on which the
> script acts coninously, or both.
>
>
Linear trackdown is nice default because for me it seems that people usually
want to "trackdown latest" working/compiling version of repository.
In the case that condition can fail/success on more than one place the
linear trackdown find the latest such place but bisect may find older one.
Other thing is that bisect needs jump into half of the internal. This "jump"
operation involved apply (or revert) given set of patches. If the test
command itself is fast than this setting state (jump) of temporary repo may
make the --bisect slower than linear trackdown.

Regarding the range of the patches to search or some pattern matching; Do
you mean that it is not possible at all with bisect trackdown ? I'm not
sure, maybe there may be a bisect patch tree which will use "halfs" of given
set of patches according the range/condtion. But that the "jump" (or move)
operation to given state has to apply / revert also patches in between (and
not matched by condition/range). It has than impact on patchtree data
structure again :)


> i'm not sure if the current --bisect command allows that?
> also the linear search is easier to understand.
> thanks rado for not letting this feature die!  (-:
>

I didn't do too much except change of the data structure. The algorithm is
the same as you wrote it, so thanks for that :)
Regarding that tests - that is right, it increases the time of the 'cabal
test'. I'll take a look how to speed up it because it can be annoying.

cheers,
Rado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100401/b162429f/attachment.htm>