I agree with Themba. I like that Fossil is a separate repo 'world' from my files. If this boundary is to be pierced, I think it should require passing in some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in this example representing "sync".
I would like some friendly tip text after rm/et al are ran, such as: "You have removed file1.h, file1.c from repo foo, you may want to remove them from your working copy." Seems like a great way to remind, teach, and help all in-context and with minimal overhead. ^K on Dec 11, 2012, Themba Fletcher <[email protected]> wrote: > >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 <[email protected]> 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 >[email protected] >http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
