On Tue, Dec 11, 2012 at 3:08 PM, K <[email protected]> wrote: > 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. >
I thought that there was some degree of agreement that the destructive commands such as rm and mv would *require* -f (or some other switch) to do the same action on disk. If that is not the case then I share Themba's concern. This *will* cause grief. There is no need to make this configurable. My preference is to mirror the behavior of mecurial or git. Git's approach of checking that the file is unchanged from the head before doing the rm is safe and convenient. > > ^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 >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
