You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@qqmail.nl> on 2012/05/13 13:50:01 UTC
RE: svn commit: r1337844 - /subversion/trunk/subversion/libsvn_wc/conflicts.c
> -----Original Message-----
> From: stsp@apache.org [mailto:stsp@apache.org]
> Sent: zondag 13 mei 2012 13:07
> To: commits@subversion.apache.org
> Subject: svn commit: r1337844 -
> /subversion/trunk/subversion/libsvn_wc/conflicts.c
>
> Author: stsp
> Date: Sun May 13 11:06:29 2012
> New Revision: 1337844
>
> URL: http://svn.apache.org/viewvc?rev=1337844&view=rev
> Log:
> * subversion/libsvn_wc/conflicts.c
> (resolve_conflict_on_node): Restore pre-r1337579 behaviour of setting the
> did_resolve output parameter to FALSE if a text conflict was implicitly
> resolved by removing the conflict marker files. Apparently this is a
> "feature" we want to keep... *grumble*
+1 on the sentiment.
>
> Modified:
> subversion/trunk/subversion/libsvn_wc/conflicts.c
>
> Modified: subversion/trunk/subversion/libsvn_wc/conflicts.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/conflicts.
> c?rev=1337844&r1=1337843&r2=1337844&view=diff
> =================================================================
> =============
> --- subversion/trunk/subversion/libsvn_wc/conflicts.c (original)
> +++ subversion/trunk/subversion/libsvn_wc/conflicts.c Sun May 13 11:06:29
> 2012
> @@ -304,7 +304,30 @@ resolve_conflict_on_node(svn_boolean_t *
> SVN_ERR(svn_wc__wq_run(db, local_abspath,
> cancel_func_t, cancel_baton,
> pool));
> - *did_resolve = TRUE;
> +
> + /* Text conflicts may be marked resolved by removing the conflict
> + * marker files. If they're already deleted, don't provide feedback. */
> + if (resolve_text && !resolve_props && !resolve_tree)
> + {
> + svn_node_kind_t node_kind = svn_node_unknown;
> +
> + if (conflict_old)
> + SVN_ERR(svn_io_check_path(conflict_old, &node_kind, pool));
> + *did_resolve = (node_kind == svn_node_file);
> +
> + if (!*did_resolve && conflict_new)
> + SVN_ERR(svn_io_check_path(conflict_new, &node_kind, pool));
> + *did_resolve = (node_kind == svn_node_file);
> +
> + if (!*did_resolve && conflict_working)
> + SVN_ERR(svn_io_check_path(conflict_working, &node_kind, pool));
> + *did_resolve = (node_kind == svn_node_file);
Did resolve should be true when either one of those is removed by removing the working queue.
After running the working queue none of those should exist, so the tests are failing.
So you should test if any one of those exists before running the wait queue. (One file found and a successful run of the working queue is enough for a TRUE at return)
Currently the buildbots fail in the basic (11) and resolve (1,3) tests.
Bert
> + }
> + else
> + {
> + /* Always provide feedback for property and tree conflicts. */
> + *did_resolve = TRUE;
> + }
> }
>
> return SVN_NO_ERROR;
>
Re: svn commit: r1337844 -
/subversion/trunk/subversion/libsvn_wc/conflicts.c
Posted by Stefan Sperling <st...@elego.de>.
On Sun, May 13, 2012 at 01:50:01PM +0200, Bert Huijben wrote:
> > -----Original Message-----
> > From: stsp@apache.org [mailto:stsp@apache.org]
> > Sent: zondag 13 mei 2012 13:07
> > To: commits@subversion.apache.org
> > Subject: svn commit: r1337844 -
> > /subversion/trunk/subversion/libsvn_wc/conflicts.c
> >
> > Author: stsp
> > Date: Sun May 13 11:06:29 2012
> > New Revision: 1337844
> >
> > URL: http://svn.apache.org/viewvc?rev=1337844&view=rev
> > Log:
> > * subversion/libsvn_wc/conflicts.c
> > (resolve_conflict_on_node): Restore pre-r1337579 behaviour of setting the
> > did_resolve output parameter to FALSE if a text conflict was implicitly
> > resolved by removing the conflict marker files. Apparently this is a
> > "feature" we want to keep... *grumble*
>
> +1 on the sentiment.
:)
> Did resolve should be true when either one of those is removed by removing the working queue.
>
> After running the working queue none of those should exist, so the tests are failing.
>
> So you should test if any one of those exists before running the wait queue. (One file found and a successful run of the working queue is enough for a TRUE at return)
>
DOH! Yes, of course.
> Currently the buildbots fail in the basic (11) and resolve (1,3) tests.
Sorry about that. Should be fixed as of r1337860.
Re: svn commit: r1337844 -
/subversion/trunk/subversion/libsvn_wc/conflicts.c
Posted by Stefan Sperling <st...@elego.de>.
On Sun, May 13, 2012 at 01:50:01PM +0200, Bert Huijben wrote:
> > -----Original Message-----
> > From: stsp@apache.org [mailto:stsp@apache.org]
> > Sent: zondag 13 mei 2012 13:07
> > To: commits@subversion.apache.org
> > Subject: svn commit: r1337844 -
> > /subversion/trunk/subversion/libsvn_wc/conflicts.c
> >
> > Author: stsp
> > Date: Sun May 13 11:06:29 2012
> > New Revision: 1337844
> >
> > URL: http://svn.apache.org/viewvc?rev=1337844&view=rev
> > Log:
> > * subversion/libsvn_wc/conflicts.c
> > (resolve_conflict_on_node): Restore pre-r1337579 behaviour of setting the
> > did_resolve output parameter to FALSE if a text conflict was implicitly
> > resolved by removing the conflict marker files. Apparently this is a
> > "feature" we want to keep... *grumble*
>
> +1 on the sentiment.
:)
> Did resolve should be true when either one of those is removed by removing the working queue.
>
> After running the working queue none of those should exist, so the tests are failing.
>
> So you should test if any one of those exists before running the wait queue. (One file found and a successful run of the working queue is enough for a TRUE at return)
>
DOH! Yes, of course.
> Currently the buildbots fail in the basic (11) and resolve (1,3) tests.
Sorry about that. Should be fixed as of r1337860.
Re: svn commit: r1337844 - /subversion/trunk/subversion/libsvn_wc/conflicts.c
Posted by Branko Čibej <br...@apache.org>.
On 13.05.2012 13:50, Bert Huijben wrote:
>> -----Original Message-----
>> From: stsp@apache.org [mailto:stsp@apache.org]
>> Sent: zondag 13 mei 2012 13:07
>> To: commits@subversion.apache.org
>> Subject: svn commit: r1337844 -
>> /subversion/trunk/subversion/libsvn_wc/conflicts.c
>>
>> Author: stsp
>> Date: Sun May 13 11:06:29 2012
>> New Revision: 1337844
>>
>> URL: http://svn.apache.org/viewvc?rev=1337844&view=rev
>> Log:
>> * subversion/libsvn_wc/conflicts.c
>> (resolve_conflict_on_node): Restore pre-r1337579 behaviour of setting the
>> did_resolve output parameter to FALSE if a text conflict was implicitly
>> resolved by removing the conflict marker files. Apparently this is a
>> "feature" we want to keep... *grumble*
> +1 on the sentiment.
If we were allowed to remove stupid features, I'd vote for killing
copies-are-branches much sooner than this one. :)
-- Brane