Hello! On Wed, Mar 31, 2010 at 9:48 PM, <[email protected]> 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
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
