In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit.
IMO, as somebody else suggested in the thread, let fossil do rm or mv only in version control. In order to satisfy need of fossil users asking for changes in file system, I suggest an option -f be given, which acts as suggested in your mail. With this option if fossil decides not to rm or mv any file in file system, it should print reason for deciding so. ----- Original Message ----- From: Richard Hipp Sent: 12/13/12 09:08 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] why does `fossil rm' not do the "real" thing? FWIW, I am following this thread with great interest. I think I understand the various points of view. I think most everybody brings up good points, and I encourage this kind of discussion. My current leanings are to change "rm" and "mv" as follows: (1) "fossil rm xyx.txt" will remove the file xyz.txt from disk if and only if an exact copy of xyz.txt exists under control. If xyz.txt has been modified or if xyz.txt has never been checked in (and the "fossil rm" is simply to reverse a prior "fossil add") then xyz.txt is unchanged. Either way, there are probably no error or warning messages, though I am sympathetic to the argument that there should be a warning message if the file is not deleted from disk. (2) "fossil mv abc.txt xyz.txt" will rename abc.txt to xyz.txt on disk provided that xyz.txt does not previously exist on disk or if xyz.txt does already exist and its content is identical to abc.txt. If xyz.txt does previously exist and is different from abc.txt (and hence would be overwritten) then the operation just fails out-right with an appropriate error message. It seems to me that the behaviors above are the most "intuitive" and provide developers with the least amount of surprise. The goal of Fossil (as it should be for any VCS) is to get out of the developer's way and just "do the right thing", so that the developer can devote maximum brain-power to working on their application, and expend a minimum number of brain-cycles thinking about Fossil and how to control it. And I think the behaviors outlined above probably best achieve this goal. But I am far from certain of that, so please do continue debating the issue. We want to get this right. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
