Contents conflict from fast-import when files were renamed

[Eric Siegerman]

On Sat, 2011-03-26 at 22:15 +0200, Eli Zaretskii wrote:
> I understand the difficulties during the initial import.  But at least
> for subsequent imports,

I don't see these as separate cases.  On either initial or
subsequent imports, you can pull in arbitrarily many revisions.
The challenge, as I see it, is designing a usable UI for such a
potentially complex situation.

I'm especially concerned about cases where a given file is
renamed multiple times in the same import stream, from A to B to
C to D.  That's a not-uncommon situation in Java, where renaming
a public class *requires* one to rename its containing *.java
file.  In Java projects, normal refactoring tends to lead to a
*lot* of file renames.

> there could be an option through which the
> user could submit a file with known renames, and then fast-import
> could use these known renames to avoid conflicts.

Where will that file come from?  Ignore the extreme case of an
initial import of an emacs-sized project's 100K+ revisions.
Suppose you're doing a subsequent import that contains 100 revs.
Will you comb through all of them looking for renames (or, if
fast-import is enhanced to detect them heuristically, looking for
both false negatives and false positives), in order to build the
rename-list file?

> Or, better,
> fast-import could look for renames in the target bzr repo and
> automatically cater to them.

One would essentially be telling fast-import in advance, using
standard "bzr mv"s on the target branch, which files *will*be*
renamed in the about-to-be-imported stream.  You'll have to
commit those manual pre-import renames, though, which will add a
rev., which will make your branch a worse representation of
upstream's revision history, even as it improves the
representation of individual files' history.  Leaving that aside,
I don't imagine that this approach does any better with the
multiple-rename problem.

The best I can think of is an iterative approach: any time
fast-import sees a possible rename (ultra-conservatively, any
revision that both adds and deletes any files at all), it stops
and lets you move things around as appropriate; then you rerun it
and it picks up where it left off (rather the way bzr-pipeline's
"pump" command deals with conflicts).  Or it could populate a
working tree for you to inspect, and ask you interactively to
tell it which files to rename where (in this scenario, you
wouldn't modify the WT (or its branch) yourself, only look at it
to decide which files match up).

> I don't know.  I cannot test this with the same repository, because
> bzr-git bails out saying that it needs nested trees.

Darn!

  - Eric