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

> -----Original Message-----
> From: Hyrum K. Wright [mailto:[email protected]]
> Sent: zaterdag 5 september 2009 20:27
> To: svn-lmwclWVctOZK/[email protected]
> Subject: svn commit: r39153 - in trunk/subversion: libsvn_wc
> tests/cmdline
> 
> Author: hwright
> Date: Sat Sep  5 11:26:48 2009
> New Revision: 39153
> 
> Log:
> When opening access batons, recursively lock all its subdirectories to
> an
> infinite depth as well.  In wc-ng, we don't have the notion of
> recursively
> opening a database; it's either open or it's not.  By making this
> change now,
> we can remove the existing complexity of determining how many levels to
> lock
> and where to lock them.

	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