Is mv preferable to delete/add from a space standpoint?

[Andrew Cowie]

I'm preparing to misuse Bazaar to track changes to a huge tree full of
mostly binary files. I did a mockup and it works great. :)

Some of those binaries are code, for example Java .jar files buried in
servlets, etc.

I did my mock up with about 4 years of releases from the vendor
upstream. I just rm'd the previous state and dropped in the next vendor
release.

My question is: would I be better off going back and each release trying
really hard to find out what has a newer version? ie, say

some/deep/path/commons-logging-api-1.1.1.jar

became

some/deep/path/commons-logging-api-1.1.2.jar, 

is it going to matter very much that a revision removes the first and
adds the second, or would we make a big saving due to saner delta
compression by somehow arranging

some/deep/path/commons-logging-api-1.1.1.jar => some/deep/path/commons-logging-api-1.1.2.jar

with `bzr mv --after`?

Everything works as is now; I'm just worried I'm killing myself from a
space efficiency standpoint. In an ideal world the delete/add case would
identify that the content being added is perhaps many bytes similar to
something already in the repository, but I'm guessing that's hardly
realistic and that it is probably storing a completely new copy and not
getting any sharing at all, which is why I ask if I should be going to
the (very considerable) effort to use bzr mv when I can.

Suggestions?

AfC
Sydney

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20100507/b89150cd/attachment.pgp