On Mar 4, 2015, at 5:28 PM, Francis Daly <fran...@daoine.org> wrote: > > On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote: >> >> >> The principle of least surprise says that Fossil should behave like other >> VCSes. > > I think that the principle of least surprise for users of fossil is > that the next version of fossil should be pretty much "the same as the > current version, only better". > > I think that the principle of least surprise for non-users of fossil is > (much) less important.
I think there are many times more future users of Fossil than present users of Fossil. It will be easier to woo them if we’re not throwing pointless differences in their way. We’re at a really good point to be making behavioral changes to Fossil right now. We have the upcoming 2.0 break point, the FLOSS Weekly interview should start moving the adoption needle, and the continuing popularity of SQLite will keep slipping Fossil into all kinds of strange places. The time to be conservative is when you have a huge installed base. For both better and worse, Fossil doesn’t have that yet. > For what it's worth, I do think that it would be useful to have a command > to affect both the repository and the filesystem in similar ways. But I > also think that historical baggage suggests that "rm" (or "mv") is not > that command. There really isn’t any historical baggage with mv. Fossil’s the weird one here. As for rm, you could be right. The only semantic agreement I found in my survey is probably accidental rather than intended. Still, I don’t see what’s wrong with making fossil rm behave the same as POSIX rm. There are an awful lot of people who have hard-won muscle memory that keeps them from shooting themselves in the foot with rm(1). It should protect them with fossil rm, too. > (I confess that I'm not clear on exactly how (or > whether) "undo" or "revert" will become involved in the new > remove-from-repository-and-filesystem command/argument. fossil mv is easy. It’s inherently undoable. The Mercurial approach to rm addresses this concern, too. It won’t allow rm without -f if you have uncommitted local modifications. If you force it, you’ve already given up on undo, IMHO. The tool tried to protect you from a potential data loss, and you made it proceed anyway. I suppose if one wanted to be *really* conservative, one could make Fossil delay the local filesystem delete until commit. It would be inconsistent with other VCSes' implementations of rm, with POSIX rm, and with the new Fossil mv. I don’t know that this margin of safety is worth the inconsistency. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
