On 12/15/12 05:26, Joe Mistachkin 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.
I'm going to speculate that this will affect very few users in the
end (and that they'll survive the change without any problems). Do you
actually know of any such cases; if so, would you care to explain the
work-flow so we get a better understanding of how they are used (more
importantly; so we understand how dangerous such a change would be)?
In particular, with the proposed change there's no chance of loss of
data as I see it. If the scripts fail, the data is still in the
repository (again, no one is suggesting fossil blindly remove files).
..while the proposed change will affect many users (in a positive way).
(And yes, I do believe that numbers matter. Not entirely, but
sufficiently in this case).
> 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.
I don't agree.
Of those I have introduced to fossil most of them have complained
about the mv/rm command ("I think I've found a bug.."). One user in
particular has never used SCM's before, so he had no preconceived ideas
with regards to SCM's. I know how bad anecdotal evidence is in a
"universal" discussion, but I firmly believe my friends and
acquaintances are representative enough for me to make a somewhat valid
extrapolation.
If every user that I introduce to fossil who uses mv or rm comes to
me and says they've found a bug, then I feel it's a problem in fossil,
not the users.
Not to mention the times it's been brought up on the mailing list and
other Internet-forums.
> 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.
Obliterate has "shun" connotations for those who have used Perforce,
If we go with different names, I would prefer another name for the commands.
mv and rm are good, because they make sense in Unix.
As a new user, I would have expected "relocate" and "obliterate" to
be a database only operations. For me, then rather than two commands
which has behavior which doesn't make sense, we'd have four.
I vote no, and again reaffirm my vote for the suggestion drh wrote
last night (local time).
--
Kind regards,
Jan Danielsson
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
