Subversion size explosion by shifting around directories; myth or fact?

I recently had to re-factor some code from a previous maintainer and initia开发者_运维技巧lly I had to do a lot of shifting directories and renaming et-all. It was relatively a small amount of code so comparing sizes didn't really reveal much. Given that subversion will always preserve each version, won't this explode the size?

I'm assuming that

repo/trunk/bobbyapple

moved to

repo/branches/oldapple

would be considered different histories based off of path and that subversion would preserve these differently (move = copy+delete). Thus if one shifts around large directories, this quickly can explode the size?

Copying is essentially free in SVN, and changes are stored as diffs. So no, this won't "explode" the size.

SVN Creates "Cheap Copies" that doesn't really make a copy of anything, it just creates a new version of the files that has been altered in the copy. It's quoted here:

Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're a Unix user, this is the same concept as a hard-link. From there, the copy is said to be “lazy”. That is, if you commit a change to one file within the copied directory, then only that file changes—the rest of the files continue to exist as links to the original files in the original directory.

refer: http://svnbook.red-bean.com/en/1.0/ch04s02.html#svn-ch-4-sect-2.1