Some questions on internals

[Frits Jalvingh]

Thanks all of you for your answers.

> 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?

john> bzr inventory --show-ids
andrew> "bzr file-id FILENAME", "bzr inventory --show-ids", "bzr log
--show-ids -v -r SOME_REVISION".
martin> bzr status --show-ids.

These would work fine I think; I'm going to try the log variant 1st
because I need to do a fake merge anyway. Extending the diff command
with a new option from a plugin would be nice, but my skills in Python
mirror my skills in singing - both horrible. Also, I cannot use bzrlib
directly as the tool I'm writing is in Java.

> 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?

Annotate was mentioned 2ce as a method to do this, but I might be
missing something because I do not see the advantage of doing annotate?
If I commit the 3.1 merge on the 3.2 branch just doing the diff on that
latest revision would give me the changes merged at their location in
the 3.2 sources. I would need to find out however which diff chunk in
the /original merge/ moved /where/ in the 3.2 version. I can of course
try to somehow recognise diffs (using some kind of fuzzy canonical hash
or something) over those versions but that can easily fail if minor
changes are made during a merge (or when chunks look alike).

Andrew, with tracking versions only, can you give me an idea on how a
merge at file level is calculated? Say you have (wildly) diverged
branches and a newer one has added heaps of code. Now you add one line
in the "old" version at line 100, then merge it upward - where it
appears at line 987 because lots of other commits changed code before it
in the new version.

You can "easily" extract the change itself (what diff to apply to
target) by looking at the shared history so that part I get. But how do
you determine a new location in target if you have no "move history"
there? Because the only way I can think of to do that is to conceptually
merge the change onto the revision closest to the source revision, and
then reapplying /all/ diffs on that file upwards to the latest version
keeping track of changes lines due to inserts and deletes.

I ask because the mechanism used might also tell me how to determine a
new location for a diff chunk.

Thanks,

Frits