Sorry to drag up an old thread, but I'm just checking back in after a lengthy absence.
On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek <no...@thewordnerd.info> wrote: > Weighing in on this, finally: > > It's interesting to me that everyone speculates that this *might* break > things for some hypothetical person, and *might* bite someone, but has > anyone here ever been bitten by it? It's the "what if" that bothers me. I use fossil as a safety net to manage an ungodly number of small maintenance projects, so I'm often not the original author of the project, and am almost never really comfortable with the code base I'm modifying. When I sync a code base to my machine and "fossil add . --dotfiles" I really appreciate the fact that I can trust fossil not to touch the disk if I accidentally add something that I don't want in there and have to remove it. In the presence of shabby and poorly maintained deploy/sync scripts, solo use of fossil, unknown modifications to the master since the last checkin, etc., the consequences of removing something from my local copy could be pretty embarrassing -- ie I could potentially blow away the only working copy of a new cusomer's web app. Not to say that I couldn't adjust to a new set of danger points, but that I do really appreciate fossil's current behavior. > > And is it not something that "fossil revert" could undo? > Is it? What about: fossil add . (whoops) -> fossil rm something fossil commit (take a phone call and forget it's fossil 2.0) sync up Now the files are gone locally, they're gone on the remote site, and fossil revert isn't going to help. This is obviously a workflow / deploy problem at its root, but it's a bit of sloppiness that fossil's current behavior forgives and the proposed behavior would not. > I don't mind avoiding the change until a 2.0 release, but I worry about > making it a setting, because I prescribe to the idea that settings add > complexity both for users and developers. > I agree about minimizing the extra overhead of a setting, but I come down personally on the side of "it's working fine, so please don't touch it." Maybe my use case varies from the norm, but I don't do fossil rm all that often and, when I do, the extra overhead of having to do "Up arrow, Ctrl-A, Alt-D, Return" afterwards doesn't bother me at all. I like explicitly taking care of this as a second deliberate step. > My $0.10 adjusted for inflation: keep the existing behavior until 2.0, then > just change it. There are plenty of settings already, please don't add > another, especially for something that we're all speculating might affect > someone who can't just revert for whatever reason. So, respectfully disagree. For me it's about not having to learn new rules about when fossil will touch my files and when it will not. Best Regards, Themba _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
