Ben Reser <b...@reser.org> writes: > But the second one is still an example of where I think the user is poorly > served by us allowing it because we're throwing a change the user desired to > be applied. > > The cp example here isn't such a huge issue because /iota is still there, but > the put examples are potentially a situation of data loss if the source file > they are putting is destroyed. > > If the cost of helping users avoid inadvertent mistakes is disallowing the rm > example above and breaking some scripts then I'm on the side of some slight > incompatibility here. > > While we certainly have endeavored to avoid gratuitous changes in command > line behavior we have made changes in the past with good reason. I don't > know if this behavior change was deliberate or not. But in my opinion it's > probably for the best.
After giving it a bit more thought, I agree that the current behavior could help us to prevent certain user mistakes. Given that an mtcc delete can also be triggered by move action sequences, I found a couple of cases where the behavior of 1.8.13 svnmucc is questionable (1.9.0-rc1 raises an error for these commands): svnmucc put iota mv iota iota2 (text changes are lost) svnmucc rm A/B mv A/A1 (inner remove is lost) The 'svnmucc rm A/mu rm A' example indeed is a bit trickier, and I can think of a couple scenarios where disallowing it could lead to some problems, e.g., with a script that calls rm for a huge amount of paths without bothering to check the ancestry relation between these paths. Still, I am fine with the current behavior, as it might also prevent unexpected removes. I reworked the corresponding tests in r1679240 [1], and am now going to close the issue. Thanks everyone! [1] https://svn.apache.org/r1679240 Regards, Evgeny Kotkov
