Philip Martin wrote:
> It's unfortunate that a temporary adm_open is required as that means
> reading the entries file twice. It's also a race since it's making a
> decision based on the read-only access baton, and that may not be
> valid once the write baton is taken. I don't think either of these is
> a serious problem, but I wonder if there is a better way to do it.
>
> How about using the existing code to open the access batons, i.e. the
> loop over dirs_to_lock and dirs_to_lock_recursive, and then doing
> something like
>
> for dir in dirs_to_lock
> get entry for dir
> if schedule delete
> for each entry in dir
> if entry is dir
> try adm_retrieve for entry
> if not locked
> take recursive lock for entry
>
> I suppose that would fail if dirs_to_lock contained an item that was
> within another schedule delete item:
Correct.
> svn commit -N foo foo/bar/baz
>
> where foo is schedule delete. Personally I'd accept that as a valid
> way to fail, but others may not agree.
This is one of the use cases.
> This is really another case for svn_wc_adm_extend, a function that was
> never written. This mythical function would have an interface like
> svn_wc_adm_open, but would not produce an error if the associated
> access baton already contained any of the required locks. It's quite
> possible this should be the default behaviour for svn_wc_adm_open.
If this is a desired functionality I can give it a try. But that new
function can't be backported to 1.0.x.
My suggestion is to use the current patch to fix the problem in 1.0.x
and I will make a new patch for 1.1.x with svn_wc_adm_extend.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 19:29:48 2004