Julian Foad <julianfoad@btopenworld.com> writes:
> >>Can we really remove an option without breaking compatibility?
> > Good point. Even though the option have no function, there might be
> > scripts using it, maybe by accident, and those will break if svn
> > doesn't accept it anymore. Maybe a deprecation warning for some
> > period of time would be the the right thing to do at the
> > moment. This will help weeding out the usage of the option with svn
> > move. Later it can be fully disabled.
>
> We can remove wrong or unintended behaviour at any time. If we
> think it is going to cause a significant amount of grief, then we
> should consider deprecating it first, but in this case I don't think
> it will cause a significant problem.
I agree that it probably won't cause many problems, but they're right
that removing the option *is* an interface change, and is not
acceptable according to the guidelines we've been using. If some
script out there currently passes '-rHEAD', then that script, which
formerly worked, would now break.
My apologies for not spotting this problem in my earlier review, btw.
The solution is fairly simple though: continue to accept the option,
and just ignore it, since that's (effectively) what we were doing
anyway. That is: accept the option, completely ignore it in
move-cmd.c, and file an issue to remove the option in 2.0.
Note that we don't have to preserve the error case behavior. If
someone has been passing '-rNUMBER', well, that never worked, so it's
not a disaster if it suddenly starts working now ("working" in the
sense of "does not error", not in the sense of "pays attention to
NUMBER", which of course it can never do).
Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 12 22:31:52 2004