On Sat, 15 Dec 2012 05:26:33 +0100, Joe Mistachkin <[email protected]>
wrote:
My opinion is that backward compatibility should be retained because
various
people, including several that may not be involved in this discussion,
have
existing scripts and other automation that relies upon the current
behavior.
Whether the current behavior being "ideal" or not is an entirely
different
debate.
My ideas on this issue are as follows:
1. Retain the existing behavior for all current commands and aliases.
It is
far too dangerous to change the DEFAULT semantics of these commands
now.
2. Add entirely new commands named "relocate" (for mv) and "obliterate"
(for
rm) that will perform actions on the repository itself as well as the
file
system.
3. For the new "relocate" command, it should raise an error if the
destination
file name already exists on the file system or in the repository.
4. For the new "obliterate" command, it should raise an error if the file
has
been changed in the current checkout.
5. Optionally, add a -f/-filesystem option to the existing mv/rm
commands if
there is consensus on this point. This new option will cause the
exact
same behavior as the new commands, including the errors as described
above.
P.S. This message is not a reply to any given message on this thread, per
se.
If you disagree with my ideas, that's fine; however, please keep the
discussion
civil.
Thanks.
I find this a confounding proposal. the backward compatibility issue
(given the proposed precautions,warnings, and length of phase out time)
will I'm sure turn out to
be a none-issue in the end.
so "-1"
from my side
--
Joe Mistachkin
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
