You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/11/03 02:08:27 UTC

Re: revert behaviour/documentation

Joe Drew <ho...@woot.net> writes:
> revert: Restore pristine working copy file (undo all local edits).
> 
> I take this to mean that svn revert in $ROOT would be the same as svn -r
> $REVISION co path://to/$ROOT, but I've been informed that it should say,
> "undo any scheduling, and any textual/property changes on versioned
> data."
> 
> (I discovered this when I removed a directory and then copied another
> on-top of where it would have been; svn revert left the copy there
> instead of putting the old copy back. This is because "we're simply
> erring on the side of safety.")
> 
> What is the consensus? Should the documentation of svn revert simply be
> changed? Should the documentation be changed, plus a new --dangerous
> flag to revert be added? Should svn revert be changed to act as I
> expected it to?

I think its current behavior is good.  To my mind, the current
documentation describes (or at least implies) that behavior... But
perhaps I'm already corrupted by too many years of Subversion
development.

If it said this instead

   revert: Restore pristine of working copy file (undo all local changes)

would that be clearer, or still not enough?

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: revert behaviour/documentation

Posted by kf...@collab.net.
Joe Drew <ho...@woot.net> writes:
> >From my original mail:
> 
> > (I discovered this when I removed a directory and then copied another
> > on-top of where it would have been; svn revert left the copy there
> > instead of putting the old copy back. This is because "we're simply
> > erring on the side of safety.")

Sorry for missing it the first time, Joe.

Yah, I think the documentation should be changed.  Changing the
behavior would be a lot of effort for only a minor gain.

I've changed it, hopefully this will be clearer:

  $ svn help revert
  revert: Restore pristine working copy file (undo most local edits).
  usage: revert PATH...
  
    Note:  this subcommand does not require network access, and resolves
    any conflicted states.  However, it does not restore removed directories.
  
  Valid options:
    --targets arg            : pass contents of file ARG as additional args
    -R [--recursive]         : descend recursively
    -q [--quiet]             : print as little as possible
    --config-dir arg         : read user configuration files from directory ARG

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: revert behaviour/documentation

Posted by kf...@collab.net.
Joe Drew <ho...@woot.net> writes:
> To me that implies even more that revert is going to do what I
> expected and not what actually happened. If it said "undo all local
> changes" and it actually did that, I'd be very happy.

Now I'm getting confused...

Which local changes is it failing to revert?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: revert behaviour/documentation

Posted by Joe Drew <ho...@woot.net>.
kfogel@collab.net wrote:

> Joe Drew <ho...@woot.net> writes:
> 
>>revert: Restore pristine working copy file (undo all local edits).
>>
>>I take this to mean that svn revert in $ROOT would be the same as svn -r
>>$REVISION co path://to/$ROOT, but I've been informed that it should say,
>>"undo any scheduling, and any textual/property changes on versioned
>>data."
>
> If it said this instead
> 
>    revert: Restore pristine of working copy file (undo all local changes)
> 
> would that be clearer, or still not enough?

To me that implies even more that revert is going to do what I expected 
and not what actually happened. If it said "undo all local changes" and 
it actually did that, I'd be very happy.

OTOH revert will cause data loss then; but why else would you be calling 
revert?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org