[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Recursive revert behavior (was: svn commit: r990916 )

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 31 Aug 2010 11:10:48 +0200

> -----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

This is an archived mail posted to the Subversion Dev mailing list.