Is mv preferable to delete/add from a space standpoint?
Andrew Cowie
andrew at operationaldynamics.com
Thu May 6 23:31:44 BST 2010
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
More information about the bazaar
mailing list