I've finally found the time to finish up the bisect command I started working on earlier in the year and it's now ready for review on the net.venge.monotone.bisect branch.
There's one item I'd like some feedback on before merging this to mainline though: In the process of bisecting, the various bisect good/bad/skip commands update the workspace to the next revision to be tested based on the results of the last test. In doing so, these commands do *not* update the workspace branch option in _MTN/options, partly because there's no guarantee that the selected revision has a branch option, or that it has only one branch option and I don't think it's sensible for bisect to fail in these cases. If, in the middle of a bisection operation, one finds the bug they're looking for, and commits a fix against that rev before completing the bisection, there's the possibility of using the current workspace branch option when they might have intended to commit to some other branch. I'm not sure what the best way to deal with this is. One option would be to make lots of other commands fail if there is a bisection operation in progress, but that doesn't seem particularly great. I'm interested if anyone else has ideas on how to handle this, or whether it's actually a real problem that even needs to be handled. Also, if anyone sees an easy way of adding an erase_descendants function to graph.cc that works similarly to erase_ancestors I could use it in bisect. I'm doing something else at the moment which works ok, but erase_descendants would be a better solution. Cheers, Derek
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
