Hi, Von: Stefan Sperling [mailto:s...@elego.de] > > > This works fine even for new directories, deleted ones, etc. > > > Caveat: It cannot do copies yet -- those will show up as simple adds. > > > > So moves and renames will lose their history? > > Yes. This is because the patch format cannot represent copies and moves. > But how often do you split out a subtree that has copied or moved items > within it? Can't you commit such changes from the existing working copy > subtree before splitting it off?
My most common (ab-)usage is to use this as a poor man's local branch feature. I'm working on some long-term task (e. G. some large refactoring or new feature), and get interrupted by some short fix which has to be developed on the fast lane. Often enough, my current working copy state is not stable enough (or does not even compile), or the fix touches the same files, but must be backportable independently, so I have to create that fix on a clean code base. Now, instead of checking out a new copy of the whole working environment (or copying the working copy, which needs a similarly long amount of time as we talk about about 2.5 Gigabytes in 58k files in about 38k folders), I just copy the one or two interesting subdirectories into a "safe" place, and locally revert all changes. After finishing and committing the intermediate fix, I delete the subdirectories, move my "safe" copies back into place, and then do "svn update". So I'm not only "detaching" subdirectories, but also "re-implanting" them afterwards. With svn 1.7, this would require at least one additional step ("downgrade" the working copy to the previous revision before the re-implant) and completely lose history for copies and renames. And especially those larger tasks are those which tend to contain copies and renames more often, as well as they have a higher likelihood to collide with "fast-lane" fixes simply due to the fact that they need a longer time. Best Regards, Markus Schaber