Disclaimer: 1) I care nothing about backward compatibility. 2) I only care about the efficiency of tools that I use to help me do my job.
On Dec 15, 2012, at 11:02 PM, Jan Danielsson <jan.m.daniels...@gmail.com> wrote: > On 12/16/12 03:28, Joe Mistachkin wrote: > Still, I think I'm right. I don't think any of the issues you've > brought up as potential serious issues so far are actual problems. But I > know for sure that the current mv/rm behavior is not what many people > (who have voiced their opinion) expect, and I'm fairly certain that the > change would overall be for the better. As a new fossil user… I agree that the rm/mv is annoying. I want the scm to help me do my job and not get in the way. The repo is a way to save the state of my project, not the working directory is a way to manage my repo. The current mv/rm supports the later mentality and I have to always do two operations in order to achieve anything which is a waste of my time. > Yes, but - as has been written so many times now that it's not even > funny any longer: rm/mv has a canonical behavior, and new users continue > to be surprised by the current behavior. This is so true. >> 1. Write a wrapper script that performs the operations. >> 2. Customize their local Fossil binaries to include the necessary code. Have already done 1 and I'm working on 2. But why would I want to have to maintain this broken behavior. It's a completely bad design and there is not one point in this thread that states why having the current functionality makes since. You have to look at it from the end-users perspective, "I want to remove this file". If it's already in the repo, then I can recover. If not, it should say the file isn't under repo control. If it's modified, maybe it should warn/prompt the user. > Or, we can change the behavior of mv/rm, implement the "unmanage" and > corresponding "move" command. Two or three users will sulk for a week, > get over it and then continue living on as nothing has happened. And all > the new users who expect the canonical behavior of mv and rm will no > longer need to be surprised. this still wouldn't help with the principle of least surprise. mv/rm are UNIX commands that have meaning… overloading them is retarded. > > We get the real rm/mv, the principle of least surprise for new users, > a canonical behavior for mv/rm, and the old behavior (just under a new > name). Everybody wins! (?) I disagree… I want new names for the other things, not for something where I have to think "rm" in unix is this, but "rm" in fossil means this. If you really didn't want to make changes on disk until commit then fine, I would agree on that, but then you have to maintain state in fossil (just like git does) until you do the commit. I think we should write a patch… publish is and see how many people actually use the patched version instead of the real version… then we'd have an argument against the conservatives that just don't like change. dan _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
