On 12/13/12 05:07, Carson Chittom wrote: > Nolan Darilek <[email protected]> writes: > >> If we're talking about adding "git" to the name because of this whole >> "rm" thing, we might as well consider "mercurial" as a candidate >> too. Mercurial behaves sensibly and removes the file automatically on >> rm. Naysayers aren't trying to make Fossil Git, we're just trying to >> make it do what most other VCSs do in these areas. > > Speaking as someone who has absolutely no investment--emotional, > professional, or otherwise--in any VCS other than fossil (and also as a > non-programmer), is "what most other VCSs do" so important?
It's not; there's an important level of indirection that you're overlooking. Other VCS's do it automatically because it's the most intuitive way to do it. I.e. we want to do like other sane VCS's because *they do it the sane way* (not because they do it in higher numbers). If all other VCS would require two separate operations, I would still want fossil do it automatically in one operation. I know it's being lazy, but sometimes it's simply easier to make the argument "everyone else is doing it", and let the readers themselves think about _why_ others do it that way. > Seems > like--while there's certainly potential room for tweaking--there's a > fundamental disconnect, philosophically, between > > 1) what is in the filesystem > 2) what is kept in version control > > and while the twain shall meet occasionally (to say the least), they are > not *necessarily* the same. Fossil, after all, is a version control > system, not a filesystem management system. It seems wholly natural to > me that "fossil rm x" should mean "remove the file x from version > control," since "version control" is fossil's raison d'etre. To my way > of thinking, VCSs which also really delete the file when removing it > from version control are violating their fundamental paradigm. Proper data separation philosophies isn't the reason I use VCS's. There are aspects of "proper design" which I find to be important, but in the face of being practical, guaranteeing history integrity, and a few other properties I could care less about conceptual proper separation of filesystem/VCS data abstraction layers. More importantly: I use a fossil in a filesystem (open, checkout, rm, mv, update, etc), and hence I expect it to do filesystem operations for me. Which is does, sans rm and mv. I don't buy the "it's separate layers" argument; a lot of working directory filesystem operations are already an integral part of fossil -- why exclude rm and mv? But sticking to the practical side of things: If people are anyways in 99.99% of the cases going to follow a "fossil rm" by an rm, and a "fossil mv" by an mv, then I think we should start thinking about whether it's really necessary to require them to do so when we're in the perfect situation to do it for them. Say fossil changes the behavior and performs the requested filesystem operations immediately, and a few people are really upset about it. I could write a wrapper script for those uses which does essentially the following: cp $file $file.tmp fossil rm $file mv $file.tmp $file That way, people can still do it in two separate steps if they want to. Now, consider how many times this will actually be used versus how many people who do "fossil rm" followed by "rm" and "fossil mv" followed by "mv". (I tried to make this point in my last mail, but I don't think people quite get what I'm trying to say). -- Kind regards, Jan Danielsson _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
