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

Re: svn commit: r39096 - trunk/subversion/libsvn_client

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 3 Sep 2009 18:56:10 +0100

On Thu, Sep 03, 2009 at 07:33:59PM +0200, Neels Janosch Hofmeyr wrote:
> Stefan Sperling wrote:
> > I think that's much simpler to follow and less bug prone.
> I actually didn't think so. I considered that, but instead of just one flag,
> we have to carry all the parameters passed through all the code. Also note
> the value
> notify->lock_state = svn_wc_notify_lock_state_inapplicable;

I think that's fairly bogus because svn/notify.c never checks this
field for any value other than svn_wc_notify_lock_state_unlocked,
and svn_wc_create_notify sets it to svn_wc_notify_lock_state_unknown
anyway. We can just remove that line.

> is only set in the first notification. Bla bla rant, that said:
> I took another look at the "action" thing, which looks kind of stupid, and
> now I technically agree. But I also found a serious problem with your way:
> it could overwrite an
> action = svn_wc_notify_tree_conflict
> in case of a replace. I'm not sure why we haven't noticed yet, but your way
> should actually break TC notifications during with-dir-replaces.
> I'll check it out. A patch for close_file() is testing now, and I'll try to
> hit the case where I think your way should break.

Oh, yes, looks like that could be a problem. Good catch.


Received on 2009-09-03 19:56:54 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.