Hi,
Von: Stefan Sperling [mailto:stsp_at_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
Received on 2011-07-25 15:04:54 CEST