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:
> 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.
Received on 2011-07-25 15:47:43 CEST