David Mankin <david@ants.com> writes:
> A common use case in my work place (still using CVS for now) is this:
> developer is making some experimental changes, gets an urgent call to
> fix another problem, updates to HEAD, gets tons of conflicts in the
> modified file, runs 'cvs update -C' to get back to a clean copy of the
> file, fixes the urgent problem, goes back to sort out what happened in
> the conflicted merge. Sure the developer could copy the modified file
> off before running 'cvs update -C' or 'svn revert', but what if he
> forgets? With CVS he is safe (and even already trained not to make
> the copy); with svn his changes are lost forever.
This use-case happens to us all the time in svn development. We're
working on a large change, and whoops, need to switch gears, so we put
the whole changeset aside:
$ svn diff > mypatch
$ svn revert . -R
$ svn up
$ edit files, commit, etc.
$ patch -p0 < mypatch
...then continue on where you left off.
Your proposal seems much clunkier to me. You'd rather have 'svn
revert' leave a bunch of 'backup' files around your working
copy... and then later hand-move them back into place? :-/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Aug 9 23:31:07 2003