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

Re: bug in can_modify()

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Thu, 17 May 2012 10:53:59 -0500

On Wed, May 16, 2012 at 11:27 PM, Greg Stein <gstein_at_gmail.com> wrote:
>
> On May 15, 2012 6:04 PM, "Hyrum K Wright" <hyrum.wright_at_wandisco.com> wrote:
>>...
>
>
>> This research comes as a result of the final test failures on the
>> ev2-export branch for commit: tree conflicts tests 4 and 8.  Both of
>> these set up the tree conflict scenario, and in doing so occasionally
>> expect an out-of-date error, which we aren't currently generating.
>> For instance, test 4 creates a file in r3, updates the working copy to
>> r2 (thereby deleting the file), does a local copy to the same location
>> as the previously created file, and then attempts to commit.  The
>> commit should fail, but the FS editor isn't returning any out-of-date
>> errors.
>
> Right. The add/copy should fail because the node already exists. I relied on
> that failure, rather than issuing an OOD. We could add that empty-target
> verification.

I think we should. The add/copy isn't failing at all in it's current
state, which means some check isn't happening as we expect it to. I
think the OOD check is the reasonable place for this failure (and the
tests seem to indicate it's what we've historically done).

>> I think the problem is that we aren't calling can_modify() enough, or
>> with the right revision argument.  For instance, in the case of a
>> copy, we only call can_modify() on the destination path if we are
>> replacing it.  It feels like we should ensure we can modify the target
>> in all instances, not just if we need to replace it.  This may also
>> apply to other editor callbacks in this file.
>
> Sure. When REPLACES_REV is INVALID, we can call check_path and verify
> nothing exists.
>
> Seem about right?

Sounds reasonable.

-Hyrum

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2012-05-17 17:54:30 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.