Re: Recursive revert behavior

"Bert Huijben" <bert_at_qqmail.nl> writes:

> This is one of the revert tests if I remember correctly?

Yes.

> I think we have to move these checks in the revert code instead of forcing
> old lock behavior. But I really don't know what we should do here, except
> for maybe revving svn_client_revertX(), to move the old behavior in the
> deprecated wrapper.
>
> For who doesn't know the full story: This is about
> * svn revert root-of-copy-operation
> vs
> * svn revert -R root-of-copy-operation
>
> With the new fully recursive lock behavior in all libsvn_client functions
> this 'svn revert WC-TREE' just works, but it is a big behavior change.
> And in this case the old behavior warned you before performing a lossy
> operation, which was kind of useful.
>
> For new code I think this kind of checks belong in the client (svn,
> TortoiseSVN, AnkhSVN, etc.) instead of in libsvn_wc or libsvn_client. But in
> this case it changes a lot of old code.

At present

   svn_wc_revert4(root_of_copy, depth=empty)

succeeds and recursively reverts the copied tree. In 1.6

   svn_wc_revert3(root_of_copy, depth=empty)

would fail with SVN_ERR_WC_NOT_LOCKED if the copied directory had
versioned subdirectories. (I've just realised that 1.6 is
inconsistent, it only errors on children that are directories not
children that are files.)

We could make revert with depth=empty fail on a copied tree unless the
tree is empty. If we do that it would probably fail with some sort of
depth error. I suppose svn_wc_revert3 could convert that to
SVN_ERR_WC_NOT_LOCKED for 1.6 compatibility?

-- 
Philip