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

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

From: Stefan Sperling <stsp_at_elego.de>
Date: Sat, 12 May 2012 18:20:54 +0200

On Sat, May 12, 2012 at 06:09:05PM +0200, Bert Huijben wrote:
> > if (resolve_props)
> > {
> > if (prop_reject_file != NULL)
> > - SVN_ERR(attempt_deletion(prop_reject_file, &found_file, pool));
> > + SVN_ERR(svn_wc__wq_build_file_remove(&work_item, db,
> > prop_reject_file,
> > + pool, pool));
>
> When resolving property and tekst conflicts this will remove the older work items for the text resolving.

Not sure what you mean here.

All I see is a missing workq merge call that I'll add now. Is that
what you mean?

>
> > else
> > resolve_props = FALSE;
> > }
> >
> > if (resolve_text || resolve_props)
> > {
> > + SVN_ERR(svn_wc__db_wq_add(db, local_abspath, work_items, pool));
> > SVN_ERR(svn_wc__db_op_mark_resolved(db, local_abspath,
> > resolve_text, resolve_props,
> > FALSE, pool));
>
> svn_wc__db_op_mark_resolved() should be extended to add the wq items within the same transaction.
> (Note that there is a very simple helper function to accomplish this)

Yes, I'll look into that.

> Without this change it is still not atomic, but at least better than before.
>
> > -
> > - /* No feedback if no files were deleted and all we did was change the
> > - entry, such a file did not appear as a conflict */
> > - if (found_file)
> > - *did_resolve = TRUE;
> > + SVN_ERR(svn_wc__wq_run(db, local_abspath,
> > + NULL, NULL, /* cancellation */
> > + pool));
> > + *did_resolve = TRUE;
>
> This might be a behavior change?

Might be, but it only affects notification. And I don't think it is
a good idea to give users the illusion that a conflict can be marked
resolved by removing the temp helper files (which is apparently what
this was about).
Received on 2012-05-12 18:21:32 CEST

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