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

bug in can_modify()

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Tue, 15 May 2012 17:04:44 -0500

Greg,
I think can_modify() (or it's uses) aren't quite correct. I don't yet
have a solution to the problem, but figured I'd record my progress
here, to see if anybody else has ideas. For the uninitiated,
can_modify() is essentially the out-of-dateness checker for the
Ev2-style interface to libsvn_fs.

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.

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.

Anyway, I'll keep tinkering and see if I can't come up with a patch,
but as you are more familiar with this area of code than I am at the
moment, I figured you'd like to know.

-Hyrum

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