goals for 0.10 development

Martin Pool mbp at canonical.com
Thu Aug 3 09:03:40 BST 2006


On  3 Aug 2006, Michael Ellerman <michael at ellerman.id.au> wrote:
> On 8/2/06, Martin Pool <mbp at canonical.com> wrote:
> >  - bzr log per file to show more relevant data, and be faster. (needs
> > speccing from ui aspect, mbp to do so, then ???)
> 
> Personally I think this is an adoption blocker. On large trees it's
> very useful to be able to say "show the log entries that touch this
> file/directory tree". Performance would be nice, but the functionality
> is key IMHO.

It works, it just is not well defined.  Specifically (iirc) 'bzr log
FILE' tells you about all mainline revisions which touched the file, and
*all* the merges into them, even the ones which did not touch it.  On a
busy tree this means that most of the logs printed are irrelevant, which
is not very helpful[*].

I would much rather see all the merges which brought that file in, but
only the merged-in revisions that affected it.

This should be pretty straightforward.

> Equally useful is being able to generate a log that includes the diff,
> this makes it easy to search for a certain addition/removal of code
> and easily identify which change caused it. Obviously you need to do
> something intelligent WRT merges.
> 
> There needs to be a way to get the diff between a revisionid and it's
> parent* without any extra fuss, ie:
>  bzr diff -r revid:michael at ellerman.id.au-20060722073445-c88ec248ad3f4799
> 
> * Obviously merges make this harder, but you can just pick one parent
> and have a flag to change which one is used.

The mooted -c option should do that.

-- 
Martin

[*] I'm reminded of the person stopping for directions outside a
software company building: "Excuse me, where am I?" "You're in a car."




More information about the bazaar mailing list