Re: RE: svn commit: r39153 - in trunk/subversion: libsvn_wc tests/cmdline

Short answer for now, cuz on phone...

This patch was done cuz Hyrum and I thought it would work. Obviously not :-P

Let's go ahead and revert. Maybe we're in good shape now, as Bert says.
However, we probably need to alter those assertions into real errors. I put
them in to ensure we used the APIs properly.

And a general locking strategy? We'll see. Not convinced yet.

Cheers,
-g

On Sep 5, 2009 10:28 AM, "Bert Huijben" <rhuijben_at_sharpsvn.net> wrote:

> -----Original Message----- > From: Hyrum K. Wright [mailto:
hyrum_at_hyrumwright.org] > Sent: zaterdag...

> Author: hwright > Date: Sat Sep 5 11:26:48 2009 > New Revision: 39153 > >
Log: > When opening ac...
       Hyrum,

[Third mail on the same subject]

Can you please revert this commit?

I don't think we can ever 'fix' access batons. The access baton model is
fixed.

We can fix the locking problems by deprecating access batons (what we did),
but we can't handle this by breaking all our compatibility wrappers. We need
a new locking api... and we have to model access batons over them.

Just look at the binding tests. (Ignore the java errors; those are caused by
r39056).

Almost every binding that using the wc apis, fails now because this changes
the definition of what an access baton is.

We need a new lock implementation, which can be recursive below a directory
or global per wc-db, or anything.

But access batons will have to be allocated per directory like they always
were.. And svn_wc_adm_open(..., adm_related, ...) has to fail when there is
already an access baton for that directory in the shared set.. Or we can
never close access batons (and never free the write lock hold inside...)

If we could have disabled it this way, why did we spend all this time
building a compatibility layer?

We promise to stay compatible, which we were until this patch, via all the
access baton handling Greg created in wc-db (and I debugged through and
through to fight those access batons close crashes over the last month).

I think a simple helper like
svn_wc__lock_recursive(wc_ctx, local_abspath, scratch_pool)

Which can be called instead of virtually all svn_wc__adm_open() calls would
make things easier too.. (Who needs an access baton return argument? ;)

But, I don't think all this is necessary, since as far as I can tell all
access batons are already related to the context now. (Since a few hours
before your commit). Maybe I missed a few places in libsvn_wc, but I expect
that we can now assume a lock without your change.

Thanks,
       Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=2391342

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2391388
Received on 2009-09-06 02:41:38 CEST