Dnia wtorek 28. listopada 2006 19:31, Aaron Bentley napisał: > Jakub Narebski wrote: >>>I notice that blame has an option to limit the annotation to recent >>>history. I can only assume that is for performance reasons. bzr >>>annotate doesn't need a feature like that, because annotations are >>>explicit in bzr's storage format. >> >> But you don't have content movement tracking. >> >>> I expect that even if we were to >>>extend annotate to track content across files, it would still be so fast >>>that we wouldn't need it. >> >> >> I think not. > > There's no question that determining content movement could involve > opening a lot of revisions, but you wouldn't need to examine: > > 1. revisions that didn't alter any lines being examined > 2. revisions that altered only the file in question > 3. revisions with multiple parents, because any lines attributed to that > merge will be the outcome of conflict resolution. (Other lines will be > attributed to one of the parents) > > I'll admit though, that when I was thinking of this, I was thinking of > annotation-based merging, a scenario in which the number of lines being > examined is typically extremely low. Well, I gues that with "annotate friendly" (weave or knit) storage annotate/blame would be faster. But fast annotate was not one of the design goals of git. How fast is "bzr annotate"? -- Jakub Narebski Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html