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

Re: svn commit: r1337844 - /subversion/trunk/subversion/libsvn_wc/conflicts.c

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 13 May 2012 14:49:14 +0200

On Sun, May 13, 2012 at 01:50:01PM +0200, Bert Huijben wrote:
> > -----Original Message-----
> > From: stsp_at_apache.org [mailto:stsp_at_apache.org]
> > Sent: zondag 13 mei 2012 13:07
> > To: commits_at_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.
Received on 2012-05-13 14:49:52 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.