On 8/8/06, Daniel Rall <dlr@collab.net> wrote:
> On Tue, 08 Aug 2006, Daniel Rall wrote:
> ...
> > I'm seeing the same behavior with Subversion trunk and 1.4.x. A merge
> > which results in a conflicted file in your WC does not produce a
> > "conflicted" merge notification.
> ...
> > This merge should give a conflict but it does not
> > A test.c
> > <<<<<<< .working
> > hello
> > =======
> > Hello
> > >>>>>>> .merge-right.r5
>
> We're calling the notification callback function provided by the 'svn'
> command-line client -- subversion/svn/notify.c:notify(). Tracing the
> code execution, we see our svn_wc_notify_t * parameter looks like:
>
> (gdb) p *n
> $1 = {path = 0x8c15730 "test.c", action = svn_wc_notify_update_add,
> kind = svn_node_file, mime_type = 0x0, lock = 0x0, err = 0x0,
> content_state = svn_wc_notify_state_conflicted,
> prop_state = svn_wc_notify_state_unknown,
> lock_state = svn_wc_notify_lock_state_unknown, revision = -1}
>
> The callback is getting invoked with an action of
> svn_wc_notify_update_add, which has no handling for a conflicts (only
> for simple adds):
>
> case svn_wc_notify_update_add:
> nb->received_some_change = TRUE;
> if ((err = svn_cmdline_printf(pool, "A %s\n", path_local)))
> goto print_error;
> break;
>
> The handling for conflicts exists in the "case
> svn_wc_notify_update_update" block.
>
> It appears that we're not expecting "svn_wc_notify_update_add" to ever
> perform a merge -- and thus threaten to create conflicts -- as we're
> seeing here.
This is one of those things where you'd think it'd be easy to fix, but
it actually causes other problems down the road. If you make it show
conflicts on adds, then it breaks dry run merges in some cases...
There's an issue about it, but I forget the number.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 9 16:13:39 2006