[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r34060 - in trunk/subversion: libsvn_client tests/cmdline

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 5 Nov 2008 10:05:37 +0100

On Tue, Nov 04, 2008 at 06:20:59PM -0800, neels_at_tigris.org wrote:
> Author: neels
> Date: Tue Nov 4 18:20:59 2008
> New Revision: 34060
>
> Log:
> Fix default return values for *TREE_CONFLICTED in the merge callbacks.
> Partly fix merge_props_changed() w.r.t. tree-conflicts.
>
> * subversion/libsvn_client/merge.c
> (merge_props_changed):
> Set *TREE_CONFLICTED to FALSE by default (was missing). Report one
> new tree-conflict. Add a TODO comment to detect other tree-conflicts.

Have we discussed yet how property changes and tree conflict changes
should interact in detail (for all steps including revert)? I'm not
saying this is not a tree conflict, but see below.

> (merge_file_changed):
> Properly propagate possible tree-conflicts from merge_props_changed().

> @@ -1010,8 +1016,22 @@ merge_file_changed(svn_wc_adm_access_t *
> /* Do property merge before text merge so that keyword expansion takes
> into account the new property values. */
> if (prop_changes->nelts > 0)
> - SVN_ERR(merge_props_changed(adm_access, prop_state, tree_conflicted,
> - mine, prop_changes, original_props, baton));
> + {
> + svn_boolean_t tree_conflicted2;
> +
> + SVN_ERR(merge_props_changed(adm_access, prop_state, &tree_conflicted2,
> + mine, prop_changes, original_props, baton));
> +
> + /* If the prop change caused a tree-conflict, just bail. */
> + if (tree_conflicted2)
> + {
> + if (tree_conflicted != NULL)
> + *tree_conflicted = TRUE;
> +
> + svn_pool_destroy(subpool);
> + return SVN_NO_ERROR;
> + }
> + }
> else
> if (prop_state)
> *prop_state = svn_wc_notify_state_unchanged;

We now bail if a prop change could not be applied to a missing file.
How is a user supposed to resolve this situation? Can the necessary
operations for resolving still be carried out, or do we happen to
disallow them because there's now a tree conflict flagged on the file?

(These question may sound rather silly, but AFAIK we have not yet
thought this through. As the problem markphip reported a while ago
shows, raising tree conflicts is only half of the picture.)

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-05 10:05:53 CET

This is an archived mail posted to the Subversion Dev mailing list.