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