You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Rall <dl...@collab.net> on 2006/08/08 21:31:56 UTC
[bug] Merge resulting in a conflicted WC file does not produce a "conflicted" merge notification
On Wed, 02 Aug 2006, Kamesh Jayachandran wrote:
> Hi All,
> I found the bogus merge-notification status demonstrated by the attached
> shell script.
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.
Modified shell script and output attached.
Re: [bug] Merge resulting in a conflicted WC file does not produce a "conflicted" merge notification
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 09 Aug 2006, Daniel Rall wrote:
> On Wed, 09 Aug 2006, Garrett Rooney wrote:
>
> > On 8/8/06, Daniel Rall <dl...@collab.net> wrote:
> ...
> > >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):
> ...
> > >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 notes that he reported this issue a while back as:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2584
>
> I'll add a (failing) test case for it based on that shell script
> recipe.
I've committed an XFAIL test for this, and am exploring a bug fix for
the underlying problem (thanks to Garrett for the discussion).
- Dan
p.s. I'll be on vacation throughout August.
Re: [bug] Merge resulting in a conflicted WC file does not produce a "conflicted" merge notification
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 09 Aug 2006, Garrett Rooney wrote:
> On 8/8/06, Daniel Rall <dl...@collab.net> wrote:
...
> >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):
...
> >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 notes that he reported this issue a while back as:
http://subversion.tigris.org/issues/show_bug.cgi?id=2584
I'll add a (failing) test case for it based on that shell script
recipe.
- Dan
Re: [bug] Merge resulting in a conflicted WC file does not produce a "conflicted" merge notification
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/8/06, Daniel Rall <dl...@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
Re: [bug] Merge resulting in a conflicted WC file does not produce a "conflicted" merge notification
Posted by Daniel Rall <dl...@collab.net>.
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.