Creating a bzr branch out of a series of tarballs

[Eric Siegerman]

On Mon, 2011-03-07 at 12:04 -0500, Aaron Bentley wrote:
> The idea is that you do "import", and then you do "mv --auto", and
then
> you do "add", and then you commit.

That doesn't work; the "mv --auto" doesn't detect any moves at
all!  This appears to be because "import" does the "add" itself,
but "mv --auto" ignores files that have already been "add"ed.
If, instead of using "import", I manually untar the newer tarball
(after deleting all the old working files, of course), "mv
--auto" does indeed find lots of moves.  (Most of them it
shouldn't have done, but that's a separate issue; see below :-/).

So there's an impedence mismatch between "import" and "mv
--auto".  ISTM that either "mv --auto" should be willing to
consider already-"add"ed files as match candidates (the automv
plugin does this, as I've just now discovered), or else "import"
should not add them in the first place.

I'd prefer the latter.  That way, one could iteratively "bzr mv
--auto --dry-run" and "bzr add" to eliminate any false positives,
then "bzr mv --auto" for real the (legitimate) moves that remain.
The down side, though, is that it would be all too easy to forget
to do the "add" manually :-(


In attempting to test the above, I picked a couple of bzr source
tarballs more or less at random to use as guinea pigs, and
happened to experience what Eli is saying -- that "mv --auto"
gets dramatically worse results than the automv plugin.  Since I
now have a recipe to reproduce this, I've logged
https://bugs.launchpad.net/bzr/+bug/730889

  - Eric