On Mon, Oct 7, 2013 at 12:18 PM, Ron Wilson <ronw.m...@gmail.com> wrote: > On Mon, Oct 7, 2013 at 2:37 PM, Andreas Kupries <andre...@activestate.com> > wrote: >> >> (*) With bisect we have the change, and this know who made it. However >> sometimes it is possible to determine a problematic line without >> having bisected during investigation, and then we do not directly know >> the relevant person. That is to me the main importance of "annotate" >> then. > > > Then you might not have your answer. Blame/Annotate tells you who the last > editor of a line was. However, that person is not necessarily the one to > blame for the problem - possibly not even for failing to find the problem. > As new things or fixes are implemented, nascent problems can appear.
True. I do try to make it a habit of always bisecting now, when I have an issue to investigate and have a reproducible case to test with. Before we had bisect annotate, possibly through several iterations, was one of the other methods available in investigations of the history of a particular piece of code. We are getting a bit off track regarding the HMI for annotate tough, and more into general debugging techniques. I tend to be more in the camp of having the user name in the annotate output. I might be able to live without that. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato Tcl'2013, Sep 23-27, New Orleans, LA, USA @ http://www.tcl.tk/community/tcl2013/ EuroTcl'2013, July 6-7, Munich, GER _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
