Greg Stein <gstein_at_gmail.com> writes:
> On Tue, Aug 10, 2010 at 14:41, Paul Burba <ptburba_at_gmail.com> wrote:
>> On Tue, Aug 10, 2010 at 12:18 AM, Greg Stein <gstein_at_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/path_at_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
Received on 2010-08-13 11:51:14 CEST