Ben Reser <ben_at_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
Received on 2015-05-13 19:21:34 CEST