Creating a bzr branch out of a series of tarballs
Eli Zaretskii
eliz at gnu.org
Mon Mar 7 18:20:44 UTC 2011
> Date: Mon, 07 Mar 2011 12:14:17 -0500
> From: Aaron Bentley <aaron at aaronbentley.com>
>
> >> I don't know how 'bzr mv --auto' matches the files up. Badly, it would seem.
> >
> > Yes, it looks like it's too lax in judging similarity.
>
> I'm sorry it's not working for you, but I did a lot of testing on this
> with the Launchpad tree (~9000 files), and stronger similarity
> requirements prevented files from matching correctly.
Maybe there should be a way to control the similarity requirements,
like automv does. E.g., although automv did a very good job for me
when importing this particular package, at least one time I needed to
bump its threshold from 55% to 61%, to avoid one erroneous rename.
And while at that, perhaps "mv --auto" could at least show the
similarity measure, as sometimes it is not as easy as in the above
case to decide whether its suggestions are good without actually
diffing the files by hand.
> I'd be interested to see the contents of rx.c and Makefile.in. It may
> be that they are empty, or nearly so.
They are not empty: one is 5K, the other 178K. Attached. Note that
"mv --auto" also decided to rename lib/ into m4/; perhaps that's
related. (I can send you the two tarballs which triggered this,
should you need that.)
It would be swell if "mv --auto" could be improved, because it's much
faster than automv.
TIA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rx.c
Type: text/x-csrc
Size: 178195 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110307/81e2262a/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.in
Type: application/octet-stream
Size: 5171 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110307/81e2262a/attachment-0001.obj>
More information about the bazaar
mailing list