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

RE: svn commit: r958908 - in /subversion/trunk/subversion: libsvn_wc/lock.c tests/libsvn_client/client-test.c

From: Bert Huijben <bert_at_vmoo.com>
Date: Sat, 3 Jul 2010 22:13:37 +0200

> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: zaterdag 3 juli 2010 21:21
> To: dev_at_subversion.apache.org
> Subject: Re: svn commit: r958908 - in /subversion/trunk/subversion:
> libsvn_wc/lock.c tests/libsvn_client/client-test.c
> On Tue, Jun 29, 2010 at 06:03, <rhuijben_at_apache.org> wrote:
> > Author: rhuijben
> > Date: Tue Jun 29 10:03:22 2010
> > New Revision: 958908
> >
> > URL: http://svn.apache.org/viewvc?rev=958908&view=rev
> > Log:
> > Add a c test to verify that we keep svn_wc_add3() compatibility working
> > when we move our own code in libsvn_client to a better route.
> >
> > * subversion/libsvn_wc/lock.c
> >  (adm_access_alloc): Allow obtaining an access baton with lock for a
> >    that is already locked in the same svn_wc__db_t instance.
> Eh? No... applications should know which nodes are locked. An attempt
> to lock the node again *should* fail. The app must use probe/retrieve
> or somesuch to fetch the access baton. (see the comment in
> svn_wc_adm_open3)

Ok.. then we should break svn_wc_add3() and probably many more functions
using access batons?

Our internal code extends the lock wc-ng style and then we *must* obtain an
access baton for that already (wc-ng style) locked directory. (The
documentation for svn_wc_add3() says (and said) that the parent access baton
set contains an access baton for the newly added node).

There is no way to obtain that access baton, without this patch as there is
no existing lock in the access baton world to hand over in this case; only
in the wc-ng world. (And we stopped creating access batons for wc-ng locks
long ago)
This fix allows obtaining an access baton version of that one wc-ng lock in
the same wc_db to keep the access baton based svn_wc_add3() compatible.

Maybe it should verify that there are no existing access batons for this
directory (it probably should), but we can't fail to create new access
batons for locked nodes if wc-ng code obtains locks wc-ng style and expects
to be able to return nodes locked to the access baton world.

See the new test in the client-tests.c which I added to specifically test
svn_wc_add3()'s behavior.

> >...
> Cheers,
> -g
Received on 2010-07-03 22:15:16 CEST

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