Greg Stein <gst...@gmail.com> writes: > On Tue, Aug 10, 2010 at 14:41, Paul Burba <ptbu...@gmail.com> wrote: >> On Tue, Aug 10, 2010 at 12:18 AM, Greg Stein <gst...@gmail.com> wrote: >>... >>> For example, >>> >>> $ svn cp A/B C >>> $ svn revert C/D/file >>> >>> That should error. >>> >>> $ svn revert C >>> >>> Should succeed, and undo the copy that was made. >> >> Since we can't revert the root of an added subtree by itself, I assume >> that if the root of your revert target is a copy, that '-R' is >> implied? > > I generally don't think at the cmdline level :-P > > Reverting the root of a copy "should" imply -R, I think. But we also > defined revert as non-recursive by default (iirc). There is also great > potential for further edits under there (structural and content) which > the user might have forgotten. An implied -R could blast (say) some > local-deletes, adds, and content changes. When the user puts a -R on > the cmdline, then we assume they have checked the subtree and are > willing to revert it all. > > Having the cmdline tool say "To revert C (a copy of repos/p...@569), > please specify -R."
The 1.6 client used to do that in some circumstances: $ svn mkdir wc/A wc/A/B $ svn revert wc/A svn: Try 'svn revert --depth infinity' instead? svn: Unable to lock 'wc/A/B' In 1.7 the behaviour has changed, probably inadvertently. The locks and the revert are now recurisive. Another behaviour change. If wc/A/B is in the repository: $ svn cp wc/A wc/C $ svn revert wc/C/B $ In 1.6 the revert does nothing, and produces no message. In 1.7 we get: $ svn revert wc/X/B Reverted 'wc/X/B' $ svn st wc A + wc/X ? wc/X/B which is an invalid wc state. -- Philip
