Ben Collins-Sussman wrote:
> 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? :-/
>
Yeah, I would, disk space is cheap. I wasn't proposing making it the default
however. If you don't approve, that's fine with me, but all you have to do
right now is leave out the diff > mypatch, and it's alllll gone. The
'Protection' afforded by requiring a parameter to revert is effectively useless
in my mind. You very quickly get to the point where the . is automatic, just
like ./blah to execute stuff.
Cheers,
Karl P
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Aug 10 07:16:37 2003