On Mon, Jul 25, 2011 at 03:04:02PM +0200, Markus Schaber wrote: > 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.
Sounds like what you really need is this as-of-yet not implemented feature: http://subversion.tigris.org/issues/show_bug.cgi?id=3625 > 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. For the time being, I'd suggest to either keep a separate working copy around that can be used for "quick fix" work, or use the workarounds described in the issue I linked above (temporary branch, or 'svn patch'). If you don't have any copies or renames in your local changeset 'svn patch' works very well and fast for this use case.
