Re: [PATCH] really skip tree conflict victims (2)

Hi tree conflict fans,

I committed the patch (after some more work) as r34158. Sorry
it's such a massive set of changes, but I didn't see how to
split it nicely.

Any working copy/adm_access gurus out there, please have a look
at the shenanigans going on in already_in_a_tree_conflict().
The issue discussed below is not quite closed. I couldn't use
svn_wc_adm_probe_try3() because it requires an associated access
baton. But already_in_a_tree_conflict() can't use any
associated batons, because it would "pollute" them with
references to their parent dirs. svn_wc_adm_probe_open3() seems
to work OK.

General remarks on r34158:

1. Need more tests. As always....

2. The new function already_in_a_tree_conflict() isn't very efficient.

3. tree_conflicts_on_update_2_1 and _3 show that an incoming tree delete
bumps the revision number inside a victim tree. I don't know how to
solve this without leaving the parent dirs incomplete. Maybe I need
to hack something in complete_directory().

4. tree_conflicts_on_update_2_3 is XFail due to an update bug. If an
update target is a single file or dir that has been deleted from the
repo, update should print a 'Skipped' message. Instead, it either
prints nothing or stops with an error. Fixing this requires moving
some functions, I think, so I'll do it in a separate commit for
clarity.

5. tree_conflicts_on_switch_2_1 and _3 are XFail because of a bug in
'svn status -u', which asks the repo for the status of items added by
switch that haven't been committed yet, and receives "path 'X' does
not exist in repository". This should be status '? ' instead of an
error. There's a related problem with 'svn status' in switch test 21.

Regards,
Steve

Quoting Julian Foad <julianfoad_at_btopenworld.com>:

> On Wed, 2008-11-12 at 11:05 +0100, Stephen Butler wrote:
>> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
>>
>> > On Tue, 2008-11-11 at 18:14 +0100, Stephen Butler wrote:

>> >> + */
>> >> +static svn_error_t *
>> >> +already_in_a_tree_conflict(char **victim_path,
>> >> + const char *path,
>> >> + svn_wc_adm_access_t *adm_access,
>> >> + apr_pool_t *pool)

...

>> >
>> > e.g. Here, strictly speaking you'd have to supply a different
>> > adm_access each time.
>>
>> Should I call svn_wc_adm_probe_try3() to try to lock each succeeding
>> parent dir?
>
> Well, yes you should, but if trying to do that turns out awkward then
> I'd be happy enough with just a comment dropped in here saying so.
>
> - Julian

-- 
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org