Some questions on internals

[Andrew Bennetts]

Frits Jalvingh wrote:
[...]
> But I run into trouble when I want to relate the comments made on that
> initial branch (3.1) with the same code merge on 3.2 or later. So I have
> a few questions:
> 
> 1. It is important to track renames. Is it possible to get the diff
> command to output the file ID of the files it shows in the output? This
> would allow me to easily find a renamed file in another branch. If not-
> is there a way to translate file id -> filename and vice versa?

It should be possible to extend the diff command, possibly in a plugin,
to show this.

There are lots of ways to map file ids to filenames and back.  Some
options are "bzr file-id FILENAME", "bzr inventory --show-ids", "bzr log
--show-ids -v -r SOME_REVISION".

(I'm assuming you're looking for ways to do that from that command line,
if you're using the bzrlib API then there are more direct
possibilities.)

> 2. I am afraid the answer is no- but.... Is there any way to relate the
> chunks of the delta caused in 3.2 with the related chunks in the delta
> to 3.1 (the initial fix merge)? Especially considering the possibility
> that merge conflicts on 3.2 would cause (small) changes in the merge
> there?

I don't think bzr can help you with this much directly.  It doesn't
internally represent changes as deltas[1], it just records that some
file's contents were "ABC" at one point and were "XYZ" later.  bzr
generates diffs for you by comparing those versions, but it doesn't
really "know" that a hunk in one diff is related to a hunk in another.
Although perhaps annotations on the merged files will help you?

-Andrew.


[1]  At a low level bzr often *stores* versions as deltas against other
     versions, for space and speed efficiency, but the model is that it
     is tracking versions, not changes between them.