On Mar 3, 2015, at 2:22 PM, Richard Hipp <d...@sqlite.org> wrote: > > On 3/3/15, Warren Young <w...@etr-usa.com> wrote: >> Is there a good reason that “fossil mv” and “fossil rm” must be followed by >> OS-level mv and rm commands? I miss the behavior of Subversion which made >> these into a single step. > > When I have suggested changing this, I got push back that the change > will break existing scripts.
Surely we can abandon such considerations at the 2.0 mark, if not before. Of the commonly-used open source VCSes (cvs, svn, bzr, hg, git) Fossil is currently the odd VCS out in requiring two-step rm *and* mv. Subversion, Mercurial, Git and Bazaar all do one-step mv. CVS doesn’t do one-step mv, but that’s because it doesn’t do mv at all. As for rm, there’s quite a lot of variance: CVS leaves the working copy alone unless you give -f. Subversion does the opposite: one-step rm unless you give --keep-local. I think this is another case of Subversion fixing a CVS problem: the wish for local removal is likely the more common case. Git is like Subversion except that there is nothing like --keep-local. I assume this is because it will only work on versioned files, so you have a copy in the Git history. The only problem I have with this logic is that it means you can trash uncommitted edits without warning. Bazaar is like Fossil: no local removal, and no CVS-like -f option to force it. I’m pretty sure Fossil isn’t trying to emulate bzr, though. Mercurial has a complex decision table for what rm does depending on the state of the file and the flags you give: http://www.selenic.com/mercurial/hg.1.html#remove This table clearly distills some serious thinking about the Right Thing which might be worth emulating in Fossil. In particular, it solves my complaint about how Git treats uncommitted changes. It also solves Paul’s problem. Anyone worried about changing the current Fossil behavior should puzzle their way through this table and see if they can see a common use case that isn’t covered. I know I’d be happy if Fossil worked like this, though I personally have never had a problem in a dozen years of using Subversion and its less-careful design. I’ll survey other VCSes if anyone cares. I just stopped here because that’s pretty much all the commonly-used open source ones today. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
