Chia-liang Kao <clkao@clkao.org> writes:
> On Sun, Jul 13, 2003 at 11:13:28AM +0100, Philip Martin wrote:
>> > - SVN_ERR (svn_wc_adm_open (&adm_access, NULL, anchor, TRUE, TRUE, pool));
>> > + SVN_ERR (svn_io_check_path (path, &kind, pool));
>> > + SVN_ERR (svn_wc_adm_open (&adm_access, NULL, anchor, TRUE,
>> > + target && (kind != svn_node_none) ? FALSE : TRUE,
>> > + pool));
>>
>> Why is it necessary to check the node kind of path? The original code
>> didn't do that.
>
> because it failed update_test#14 (update_deleted_missing_dir) without the
> check. It seems in the case update would fail because it assumes other
> directory under anchor is locked. so I just special-cased it to fallback the
> original behavior - treelock the anchor.
I don't like it, it all looks a bit ad-hoc. Do other people think we
should be applying patches like this? The patches probably work (I
haven't tried them) and so solve the problem Chia-liang Kao is having.
It's just that if the locking is going to be changed I'd prefer code
that is "more elegant", for some value of "elegant".
Consider 'svn up foo', in most cases it needs a non-recursive lock for
the parent of foo, and a recursive or non-recursive lock for foo
itself if foo is a versioned directory. This allows for foo to get
deleted during the update. The only possible exceptions are if foo is
a working copy root, or if foo is '.' (I suspect the existing code
doesn't handle deletes for these cases, think there is already an
issue for the related 'svn switch' problem.)
The locking code for 'svn rm' needs to do the same locking as 'svn up'
although 'svn rm' doesn't have a non-recursive case. I'd like to see
a simple function that does the right thing that both could share, it
should probably be used instead of svn_wc_get_actual_target function,
as that opens and reads the entries files, and then discards the
batons.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 13 22:15:28 2003