> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: dinsdag 31 augustus 2010 10:26
> To: dev_at_subversion.apache.org
> Subject: Re: svn commit: r990916 - in
> /subversion/trunk/subversion/bindings/javahl/native: ClientContext.cpp
> ClientContext.h
>
> "Bert Huijben" <bert_at_qqmail.nl> writes:
>
<snip> See original thread
>
> > The current recursive lock code for multi-db doesn't have stable
> behavior
> > over added and removed directories, while the single-db code has. I
> didn't
> > feel like reinventing a complete lock store system like the old
> access
> > batons just to fix these issues for multi-db. (Single-db has a real
> > recursive lock, so it only has to delete the lock from the root)
>
> The recursive lock is a problem for non-recursive revert as it no
> longer returns SVN_ERR_WC_NOT_LOCKED, see the XFail in revert_tests.py
> (and our client explicitly checks for that error). We can fix the
> recursive behaviour of revert, but can we fix the return value? Is it
> acceptable to return SVN_ERR_WC_NOT_LOCKED when we have a recursive
> lock?
This is one of the revert tests if I remember correctly?
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.
Bert
Received on 2010-08-31 11:12:33 CEST