git and bzr
Jakub Narebski
jnareb at gmail.com
Tue Nov 28 18:43:39 GMT 2006
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
More information about the bazaar
mailing list