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