Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sun, Dec 16, 2012 at 05:13:24PM -0800, Joe Mistachkin wrote: Chad Perrin wrote: zsh: sports metaphor not found Sorry, I was attempting to inject some humor into this discussion because it has grown very tedious. I guess you didn't find my rejoinder amusing. HDDs also suffer wear and tear during I/O operations, and new SSDs easily last long enough that, relative to HDDs, this should no longer be any kind of problem. In fact, the major problem is not that SSDs have a limited number of writes; so do HDDs. The problem is that you can know in advance how many you have, while with HDDs it's a roll of the dice. My original point of doing (potentially several GB of) superfluous file I/O still stands. . . . unless you pay attention to what I said. It's not just bikeshedding if it's a matter of actual tool usability. Funny, I've been using Fossil for years and this usability problem has never bothered me. In fact, quite the opposite. The point has been made many times that the usability issue under discussion is relevant to certain people, while certain others may not experience the same issue. The question under discussion is how to determine which is the more important group to satisfy, which to some extent involves an estimate of numbers. Considering the number of new users who have not yet started using Fossil but might some day, and who are quite familiar with both Unix environments and other VCSes newer than CVS, combined with the number of current users who find the current behavior of `mv` and `rm` somewhat confounding, is surely much greater than the number of people currently using Fossil who never encounter other VCSes and Unix environments to give a crap, I fall on the we should change things side of the debate. . . . which works great for new users! Oh, wait, no it doesn't. There is always a learning curve for new users, however slight. I suppose that means we should make the curve as steep as possible, regardless of whether it actually buys us anything, then. Right? If they can't hack it, let them use rcs instead. They can eat cake while they're at it. I've read them all. It was easy. I didn't want to read them all. Okay. Why didn't you say so in the first place? Because *you* never really interact with the rest of the world, the fact the rest of us do is irrelevant, I guess. It's all about you. I'm growing increasingly tired of your attempts to insult me. That's not an insult. It's marveling at your egocentric dismissal of everyone in the world with a different computing experience than you, which some of the rest of us might find insulting if we were as thin skinned as you. Your lack of experience with those other systems does not in any way invalidate the question. I never stated that I lack experience with those other systems; however, I use them only very rarely. That's a lack of experience, just as a trial lawyer of twenty years would refer to my involvement in Youth In Government twenty years ago in the trial law part of the program as a lack of experience. I don't really consider occasional dilettentes experienced in a significant sense. Really, I think the thing that irks me most about many of the arguments on your side of the debate is their condescending dismissal of the possibility that someone might have a meaningful argument for changing the behavior of `mv` and `rm` Fossil commands, even if it is not deemed compelling enough to change things by core contributors. In previous emails, by contrast, I have tried to address concerns of those who disagree with me on the overall desirability of the proposed changes by suggesting deprecation followed by eventual change in accord with semantic versioning. Others have made similar suggestions to try to satisfy everyone involved. You, meanwhile, have taken the position of Screw you and the horse you rode in on; you can have some other command instead that doesn't actually address core concerns you've raised. Perhaps you should think about that before blowing people's concerns off as meaningless and accusing them of insulting you. Even if someone has insulted you, that doesn't justify your own insulting lack of regard for anyone who might not have exactly the same software usage habits as you. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sun, Dec 16, 2012 at 05:02:23PM -0800, Joe Mistachkin wrote: Chad Perrin wrote: If you use bleeding edge versions, you should already be prepared to deal with changes in behavior. I don't see the problem. I help write the bleeding edge versions. Therefore, it is useful that I run them on a daily basis as well. . . . therefore, I don't see the problem. There will always be someone disenfranchised. The question is whether we should disenfranchise people who are very, very bad at software management, or disenfranchise people who want their software to work in a reasonable manner. I would just like to point out here that, contrary to your assertion to the contrary, I do care about other people besides myself in this matter. I'd call it a suggestion, rather than an assertion. I don't think I quite explicitly made that charge. It's nice to know you care, though. Perhaps you'd like to acknowledge that fact in future comments rather than phrase your commentary like that two which I responded. Show me where I demonized anyone. I didn't imply people are stupid, the way some emails opposed to changing `rm` and `mv` have. I didn't say people were morally reprehensible, acting maliciously to make others' lives difficult. I just asked about whether the primary priority should be for people who don't care enough about their work to pay attention to their tools. It's very subtle, but it's there. To quote, someone who will never pay attention to warnings. Out of curiousity, how many warnings given by software do *YOU* routinely ignore (e.g. web site security, etc)? Someone who will never pay attention to warnings isn't a demonization. It's a characterization of people who, well, never pay attention to warnings -- which, you may note, was obviously not directed at you personally, in any case. There are people out there who never pay attention to warnings, and people who use four-year out of date software with critical security vulnerabilities left unpatched. Screws fall out all the time. The world is an imperfect place. Please tell me who else would not notice warnings over a gentle deprecation period with warnings other than: 1. those who never pay attention to warnings 2. those who go for ridiculously long times without updating software I'm willing to acknowledge the existence of people in large numbers falling through that crack if you can point out such a crack through which large numbers of people might fall. The world is, after all, an imperfect place (see above). I just see no evidence of them in any arguments for inflexible stasis of software defaults so far. . . . except that, given your reactions to some of the other things I said, you seem inclined to take statements as insults when they obviously are not intended as insults, so the problem isn't really solved on your end. Right? After having read several of your previous posts to others on this list, including several containing insults, it seemed to be a fair assumption. I recommend you read for denotative meaning of words rather than for imagined tone in the future. Emails do not generally come with tone of voice. That seems like another implementation detail. I'm not sure how to respond to this. Yes, changes to software do require changing the implementation. When taken in isolation, ignoring everything else I said about implementation details, I suppose it's easy to pretend I said something nonsensical. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Do you two need a room? If so, there's a local so-called love hotel I can book for you in two-hour slots. On 18 December 2012 13:00, Chad Perrin c...@apotheon.net wrote: On Sun, Dec 16, 2012 at 05:02:23PM -0800, Joe Mistachkin wrote: Chad Perrin wrote: If you use bleeding edge versions, you should already be prepared to deal with changes in behavior. I don't see the problem. I help write the bleeding edge versions. Therefore, it is useful that I run them on a daily basis as well. . . . therefore, I don't see the problem. There will always be someone disenfranchised. The question is whether we should disenfranchise people who are very, very bad at software management, or disenfranchise people who want their software to work in a reasonable manner. I would just like to point out here that, contrary to your assertion to the contrary, I do care about other people besides myself in this matter. I'd call it a suggestion, rather than an assertion. I don't think I quite explicitly made that charge. It's nice to know you care, though. Perhaps you'd like to acknowledge that fact in future comments rather than phrase your commentary like that two which I responded. Show me where I demonized anyone. I didn't imply people are stupid, the way some emails opposed to changing `rm` and `mv` have. I didn't say people were morally reprehensible, acting maliciously to make others' lives difficult. I just asked about whether the primary priority should be for people who don't care enough about their work to pay attention to their tools. It's very subtle, but it's there. To quote, someone who will never pay attention to warnings. Out of curiousity, how many warnings given by software do *YOU* routinely ignore (e.g. web site security, etc)? Someone who will never pay attention to warnings isn't a demonization. It's a characterization of people who, well, never pay attention to warnings -- which, you may note, was obviously not directed at you personally, in any case. There are people out there who never pay attention to warnings, and people who use four-year out of date software with critical security vulnerabilities left unpatched. Screws fall out all the time. The world is an imperfect place. Please tell me who else would not notice warnings over a gentle deprecation period with warnings other than: 1. those who never pay attention to warnings 2. those who go for ridiculously long times without updating software I'm willing to acknowledge the existence of people in large numbers falling through that crack if you can point out such a crack through which large numbers of people might fall. The world is, after all, an imperfect place (see above). I just see no evidence of them in any arguments for inflexible stasis of software defaults so far. . . . except that, given your reactions to some of the other things I said, you seem inclined to take statements as insults when they obviously are not intended as insults, so the problem isn't really solved on your end. Right? After having read several of your previous posts to others on this list, including several containing insults, it seemed to be a fair assumption. I recommend you read for denotative meaning of words rather than for imagined tone in the future. Emails do not generally come with tone of voice. That seems like another implementation detail. I'm not sure how to respond to this. Yes, changes to software do require changing the implementation. When taken in isolation, ignoring everything else I said about implementation details, I suppose it's easy to pretend I said something nonsensical. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Disclaimer: 1) I care nothing about backward compatibility. 2) I only care about the efficiency of tools that I use to help me do my job. On Dec 15, 2012, at 11:02 PM, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 12/16/12 03:28, Joe Mistachkin wrote: Still, I think I'm right. I don't think any of the issues you've brought up as potential serious issues so far are actual problems. But I know for sure that the current mv/rm behavior is not what many people (who have voiced their opinion) expect, and I'm fairly certain that the change would overall be for the better. As a new fossil user… I agree that the rm/mv is annoying. I want the scm to help me do my job and not get in the way. The repo is a way to save the state of my project, not the working directory is a way to manage my repo. The current mv/rm supports the later mentality and I have to always do two operations in order to achieve anything which is a waste of my time. Yes, but - as has been written so many times now that it's not even funny any longer: rm/mv has a canonical behavior, and new users continue to be surprised by the current behavior. This is so true. 1. Write a wrapper script that performs the operations. 2. Customize their local Fossil binaries to include the necessary code. Have already done 1 and I'm working on 2. But why would I want to have to maintain this broken behavior. It's a completely bad design and there is not one point in this thread that states why having the current functionality makes since. You have to look at it from the end-users perspective, I want to remove this file. If it's already in the repo, then I can recover. If not, it should say the file isn't under repo control. If it's modified, maybe it should warn/prompt the user. Or, we can change the behavior of mv/rm, implement the unmanage and corresponding move command. Two or three users will sulk for a week, get over it and then continue living on as nothing has happened. And all the new users who expect the canonical behavior of mv and rm will no longer need to be surprised. this still wouldn't help with the principle of least surprise. mv/rm are UNIX commands that have meaning… overloading them is retarded. We get the real rm/mv, the principle of least surprise for new users, a canonical behavior for mv/rm, and the old behavior (just under a new name). Everybody wins! (?) I disagree… I want new names for the other things, not for something where I have to think rm in unix is this, but rm in fossil means this. If you really didn't want to make changes on disk until commit then fine, I would agree on that, but then you have to maintain state in fossil (just like git does) until you do the commit. I think we should write a patch… publish is and see how many people actually use the patched version instead of the real version… then we'd have an argument against the conservatives that just don't like change. dan ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sat, Dec 15, 2012 at 03:36:43PM -0800, Joe Mistachkin wrote: Chad Perrin wrote: If you are not ready for changes in default behavior, don't upgrade to the next major version number. There is no good argument for software defaults to be set in stone for all time. Just use reasonable caution when releasing changes to default behavior. That is somewhat difficult in my case as I typically run trunk (or very close to it) to use the new/modified features I've been adding. If you use bleeding edge versions, you should already be prepared to deal with changes in behavior. I don't see the problem. It shouldn't be a surprise, as the migration is currently proposed, unless all those users never upgrade Fossil SCM between now and the some- future-time final change in functionality, thanks to the behavior migration warnings and other indications (including, presumably, a major version number change) that should apply along the way. That is an exceptionally bad assumption. We've had users that did not upgrade over a year. Subsequently, they would sometimes notice a significant behavioral change and report it to us. If rm suddenly started deleting files, I suspect that could induce panic, even if the action could be undone. There will always be someone disenfranchised. The question is whether we should disenfranchise people who are very, very bad at software management, or disenfranchise people who want their software to work in a reasonable manner. Should all software never ever break any backward compatibility ever, just because something may be automated somewhere by someone who will never pay attention to warnings given by the software itself or will skip many intermediate versions before upgrading to a new, post-change version? Attempting to demonize people for relying on the current behavior seems to be in poor taste. Show me where I demonized anyone. I didn't imply people are stupid, the way some emails opposed to changing `rm` and `mv` have. I didn't say people were morally reprehensible, acting maliciously to make others' lives difficult. I just asked about whether the primary priority should be for people who don't care enough about their work to pay attention to their tools. Should we always plan changes only for the sake of the most irresponsible users? Being openly hostile to users (i.e. by calling them irresponsible) is also in poor taste. Software that is openly hostile to its user base does not end up being too popular. Finding examples of this is within the industry is left as an exercise for the reader. I'm not calling users in general irresponsible -- only irresponsible users. There *are* irresponsible users in the world, just as there are developmentally disabled people, stupid people, and actually *bad* people. Pretending there aren't such people doesn't change the facts, and we should damned well be able to account for such people when making policy. I'm not even saying that all people who disagree with the need for a change in default `rm` and `mv` behavior are irresponsible. I'm just pointing out that many of the problems raised are non-issues except to irresponsible users, and saying that I think this is a bad prioritization strategy. If to you it's perfectly reasonable to leave it as-is, we aren't even speaking the same language. I'm not sure if this is an attempt to insult me or not; however, I'll just assume that it is not. Not changing something in an incompatible way is always a reasonable choice. I think we'll have to agree to disagree on this. It's not an attempt to insult you. Problem solved. . . . except that, given your reactions to some of the other things I said, you seem inclined to take statements as insults when they obviously are not intended as insults, so the problem isn't really solved on your end. Right? There are several other problems with changing the current behavior: 1. The opposite of add is remove. The add command does not modify the file system. It merely records something to be done for the next commit. Similarly, the current remove command does this as well. The opposite of add could be delete or subtract instead. Notice that the ideas of leaving delete as-is and/or adding a remove alias for it have been raised, and that rm is not exactly the same as remove. I think this point of yours does not exactly hold water. 2. If the mv and rm commands were to be changed to perform some action during commit, that would be very confusing as commit should only modify the repository. On the other hand, if the mv and rm commands were to perform their file system actions prior to commit, would revert need to bring the previous files back to life? That does not make sense. This seems to me like a matter for discussion of implementation, and not of whether the change should be made at all. 3. Related
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sun, Dec 16, 2012 at 11:06:57AM -0500, daniel gregory wrote: I think we should write a patch… publish is and see how many people actually use the patched version instead of the real version… then we'd have an argument against the conservatives that just don't like change. That's not a bad idea, though I think it should be maintained alongside the unpatched version with equal maintenance and availability for both. Otherwise, it may be that almost nobody uses it. I may not even use it, preferring to script around the undesirable old behavior, if the alternative is to have to patch it myself every time I upgrade or hunt down some non-canonical location for downloads. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sat, Dec 15, 2012 at 06:28:52PM -0800, Joe Mistachkin wrote: Jan Danielsson wrote: First, I feel you're inventing problems to make arguments in order to exclude features which address real world issues. (A little like the script issue brought up earlier). Straw man argument. Five yard penalty, still first down. zsh: sports metaphor not found Second (slightly off-topic), What's the problem with SSD and large files? I have been using SLC SSD's since 2007, and since 2008 almost exclusively mixed SLC and MLC SSD's on both servers and clients. On two machines I regularly handle multi-GB files, and have not encountered any issues which I haven't encountered with spinning-platter disks. I fail to see why I would suddenly start having issues with large files because I'm using fossil on SSD:s? (which, I'll admit, I have not). The point here is wear-and-tear on the SSD, which have a finite limit of the number of bytes they can write during their useful lifetime. Sorry if this point was not clear in my previous response. HDDs also suffer wear and tear during I/O operations, and new SSDs easily last long enough that, relative to HDDs, this should no longer be any kind of problem. In fact, the major problem is not that SSDs have a limited number of writes; so do HDDs. The problem is that you can know in advance how many you have, while with HDDs it's a roll of the dice. There are lots of ways you can screw up, but the important thing is that you can recover. I also think we have to assume that the normal case is that people won't screw up, and assume that normally people double check before they do something. (Wasn't that one of the insults directed at those of us who want real mv/rm? That we just blindly do things without thinking things through? Ironic twist (yes, I know you weren't the one to say it, but someone else did)). I just think there should be a clear division between Fossil commands that interact with the file system and those that do not. I expect the clean and revert commands to deal with modifying files in the file system; however, I would not expect the add, mv, and rm commands to do that. I think there should be a clear division, as well. Those commands that mimic the form of filesystem operations (e.g. `rm`) should, where at all reasonable to do so, be on the filesystem interaction side of that divide. Those that do not (e.g. `delete`) can be on the other side of it. Plus, if you know you're setting yourself up for such a situation, then don't use the real rm; use the command which has retained the old behavior (unmanage, for instance). Bike shedding. The new command, say realrm (or whatever) could just as easily be made to perform the semantics you desire instead of breaking backward compatibility by modifying existing commands. It's not just bikeshedding if it's a matter of actual tool usability. Yes. (I recommend you read through the threads; some of the issues you raise have been discussed previously). Frankly, I've been trying to avoid getting involved in this discussion at all. If people really want mv and rm to perform file system operations, they can already: 1. Write a wrapper script that performs the operations. . . . which works great for new users! Oh, wait, no it doesn't. 2. Customize their local Fossil binaries to include the necessary code. . . . which perfectly solves the POLS problem for both new users and people who have to interact with the rest of the world sometimes! Oh, wait, no it doesn't. Also, I have read most of the messages in this thread; however, I think it may be next to impossible to read them all. I do not even know how many messages there are in total. I've read them all. It was easy. Stage 1: (a) fossil rm -f deletes from disk (if it is safe to do so) (b) fossil rm works as currently, but prints a warning message that it will delete from disk in a future release. (c) fossil delete works as currently (d) fossil unmanage added as an alias for fossil delete Stage 2 (after a stage 1 has been released for a while): (e) fossil rm works just like fossil rm -f I agree with (1a), (1c), and (1d). I disagree with all the others, especially (2e). . . . but not for any solid reasons I've seen. How come all these points you listed aren't issues with other source management systems which have real rm/mv? Frankly, I don't use the those other systems on a regular basis and I really do not care what they do. Sorry. Because *you* never really interact with the rest of the world, the fact the rest of us do is irrelevant, I guess. It's all about you. Don't forget that there was a real question in that. You claim there are huge problems with the proposed new behavior of `rm` and `mv` for Fossil SCM, but the example of other VCSes makes it clear these
Re: [fossil-users] why does `fossil rm' not do the real thing?
Chad Perrin wrote: If you use bleeding edge versions, you should already be prepared to deal with changes in behavior. I don't see the problem. I help write the bleeding edge versions. Therefore, it is useful that I run them on a daily basis as well. There will always be someone disenfranchised. The question is whether we should disenfranchise people who are very, very bad at software management, or disenfranchise people who want their software to work in a reasonable manner. I would just like to point out here that, contrary to your assertion to the contrary, I do care about other people besides myself in this matter. Show me where I demonized anyone. I didn't imply people are stupid, the way some emails opposed to changing `rm` and `mv` have. I didn't say people were morally reprehensible, acting maliciously to make others' lives difficult. I just asked about whether the primary priority should be for people who don't care enough about their work to pay attention to their tools. It's very subtle, but it's there. To quote, someone who will never pay attention to warnings. Out of curiousity, how many warnings given by software do *YOU* routinely ignore (e.g. web site security, etc)? . . . except that, given your reactions to some of the other things I said, you seem inclined to take statements as insults when they obviously are not intended as insults, so the problem isn't really solved on your end. Right? After having read several of your previous posts to others on this list, including several containing insults, it seemed to be a fair assumption. That seems like another implementation detail. I'm not sure how to respond to this. Yes, changes to software do require changing the implementation. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Chad Perrin wrote: zsh: sports metaphor not found Sorry, I was attempting to inject some humor into this discussion because it has grown very tedious. HDDs also suffer wear and tear during I/O operations, and new SSDs easily last long enough that, relative to HDDs, this should no longer be any kind of problem. In fact, the major problem is not that SSDs have a limited number of writes; so do HDDs. The problem is that you can know in advance how many you have, while with HDDs it's a roll of the dice. My original point of doing (potentially several GB of) superfluous file I/O still stands. It's not just bikeshedding if it's a matter of actual tool usability. Funny, I've been using Fossil for years and this usability problem has never bothered me. In fact, quite the opposite. . . . which works great for new users! Oh, wait, no it doesn't. There is always a learning curve for new users, however slight. I've read them all. It was easy. I didn't want to read them all. Because *you* never really interact with the rest of the world, the fact the rest of us do is irrelevant, I guess. It's all about you. I'm growing increasingly tired of your attempts to insult me. Your lack of experience with those other systems does not in any way invalidate the question. I never stated that I lack experience with those other systems; however, I use them only very rarely. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
I don't really care which behavior is the default. I've dealt with both long enough that neither is surprising, and my workflow doesn't change enough to notice for this. I'm just tired of seeing the bogus claim that one is somehow surprising and natural and one isn't. The only thing I want to avoid is a builtin fossil rm that can do different things in different repos that are supposedly running the same version of fossil. Well, ok, I also really don't want the silly git behavior of having to force the SCM to record a move in the repo that's already happened on disk. On Sun, 16 Dec 2012 11:06:57 -0500 daniel gregory gig...@gmail.com wrote: Yes, but - as has been written so many times now that it's not even funny any longer: rm/mv has a canonical behavior, and new users continue to be surprised by the current behavior. This is so true. Only if you behave the way you want to: not for something where I have to think rm in unix is this, but rm in fossil means this. It doesn't matter whether it touches the work space or not, rm in fossil means something different than rm in unix. It *has* to. Unix doesn't know anything about fossil repositories, so it's rm *can't* deal with them. The only thing that would be surprising is if fossil rm actually did what unix rm does, and removed a file from disk without changing the repo in any way. The only way you can be surprised by either behavior is if you do what daniel suggests, and *don't* think about what you're doing. This kind of surprise - cause by thoughtlessly extrapolating from a *different* command set - is not what POLS is about. Otherwise, Unix would have a DEL command because people coming from VMS/DOS/RSTS/etc were surprised that it didn't. I don't see anything *in fossil* that would lead one to expect rm or mv to have either behavior. My gut reaction: This is a silly argument, caused by people being overly attached to those two-letter commands. Just nuke them both. del and ren both work fine, and are only one character longer. A --filesystem/-f flag would be nice if the commands don't change. If they change to touch the filesystem - well, make sure they always queue changes to the repo for the next commit, even if they fail to change the file system for some reason. And a flag that says repo only, ignore the file system would probably be appreciated by some. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, 14 Dec 2012 20:26:33 -0800 Joe Mistachkin sql...@mistachkin.com wrote: 1. Retain the existing behavior for all current commands and aliases. It is far too dangerous to change the DEFAULT semantics of these commands now. Does it imply that Fossil should not break backward comp. ever in order to evolve in certain design choices which were, as Richard himself stated the use of text/x-fossil-wiki for comment and ticket text was a mistake. ? Sincerely, Gour -- Not by merely abstaining from work can one achieve freedom from reaction, nor by renunciation alone can one attain perfection. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sat, 15 Dec 2012 05:26:33 +0100, Joe Mistachkin sql...@mistachkin.com wrote: My opinion is that backward compatibility should be retained because various people, including several that may not be involved in this discussion, have existing scripts and other automation that relies upon the current behavior. Whether the current behavior being ideal or not is an entirely different debate. My ideas on this issue are as follows: 1. Retain the existing behavior for all current commands and aliases. It is far too dangerous to change the DEFAULT semantics of these commands now. 2. Add entirely new commands named relocate (for mv) and obliterate (for rm) that will perform actions on the repository itself as well as the file system. 3. For the new relocate command, it should raise an error if the destination file name already exists on the file system or in the repository. 4. For the new obliterate command, it should raise an error if the file has been changed in the current checkout. 5. Optionally, add a -f/-filesystem option to the existing mv/rm commands if there is consensus on this point. This new option will cause the exact same behavior as the new commands, including the errors as described above. P.S. This message is not a reply to any given message on this thread, per se. If you disagree with my ideas, that's fine; however, please keep the discussion civil. Thanks. I find this a confounding proposal. the backward compatibility issue (given the proposed precautions,warnings, and length of phase out time) will I'm sure turn out to be a none-issue in the end. so -1 from my side -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Gour wrote: Does it imply that Fossil should not break backward comp. ever in order to evolve in certain design choices which were, as Richard himself stated the use of text/x-fossil-wiki for comment and ticket text was a mistake. ? In my opinion, breaking backward compatibility with a piece of software that is widely deployed and that lots people depend on every single day should never be taken lightly. In this case, since Fossil is a command line tool, there are almost certainly build scripts, graphical wrappers, continuous integration systems, and other automation that would be potentially broken by such a change. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
j. v. d. hoff wrote: I find this a confounding proposal. Would you care to explain exactly what you find confounding about it? It provides the requested functionality; however, it does so in a manner that is respectful to those who are depending on the current functionality. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sat, 15 Dec 2012 10:56:20 +0100, Joe Mistachkin sql...@mistachkin.com wrote: j. v. d. hoff wrote: I find this a confounding proposal. Would you care to explain exactly what you find confounding about it? has all been set way too often in this way too long thread: POLS comes again to mind. I can tell you that I _was_ surprised (being also a user of svn and hg) when I installed fossil quickly read through the help (ah yes, ci, add, pull, push, rm, mv, stat, log -- default naming scheme for default tasks), started to use it and it turned out mv/rm did _not_ behave as usual (and for all the reasons stated over and over again: which would be more sensible). by delegating the desired behaviour to `obliterate' or whatever and keeping rm as it is you guarantee that this will happen over and over again to other people. why? for no good reason at all I can see. I'd bet that in this arena (recent users) lurks much more trouble by failing to meet the usual (good, mind you) behaviour than by changing current defaults after a transition period. It provides the requested functionality; however, it does so in a manner that is respectful to those who are depending on the current changing the default (including the transition period) is no sign of disrespect to anybody. functionality. and I do not buy the it'll be really dangerous for so many people prophecy. of course, if one really tries hard one can manage to get things messed up on disk (change lots of things in tracked files, but don't ever check in (clever) and then decide to stop tracking the files and issue 'fossil rm' assuming the files are left alone on disk and only then discover they were not). the transition period should guarantee that this will not evelove into a real-world problem I'd say. j. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
j. v. d. hoff wrote: POLS comes again to mind. The Principle of Least Surprise is not static. Changing the current behavior would be a huge (and potentially unpleasant) surprise for those who are very actively using Fossil now. I can tell you that I _was_ surprised (being also a user of svn and hg) when I installed fossil quickly read through the help (ah yes, ci, add, pull, push, rm, mv, stat, log -- default naming scheme for default tasks), Of course, there are much bigger differences between Fossil and those other systems than the semantics of mv and rm. and I do not buy the it'll be really dangerous for so many people prophecy. Obviously, I do buy it. Breaking compatibility is generally bad. It's even worse when other _software_ (i.e. not humans) may depend on the current semantics. The surface area of Fossil is the set of command line options it exposes, since it's a command line tool. In this case, it would not be unlike changing the default behavior of the Unix rm command to implicitly include the -f option. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sat, 15 Dec 2012 12:03:26 +0100, Joe Mistachkin sql...@mistachkin.com wrote: j. v. d. hoff wrote: POLS comes again to mind. The Principle of Least Surprise is not static. Changing the current behavior would be a huge (and potentially unpleasant) surprise for those who are very actively using Fossil now. I can tell you that I _was_ surprised (being also a user of svn and hg) when I installed fossil quickly read through the help (ah yes, ci, add, pull, push, rm, mv, stat, log -- default naming scheme for default tasks), Of course, there are much bigger differences between Fossil and those other systems than the semantics of mv and rm. and I do not buy the it'll be really dangerous for so many people prophecy. Obviously, I do buy it. Breaking compatibility is generally bad. It's even worse when other _software_ (i.e. not humans) may depend on the current semantics. The surface area of Fossil is the set of command line yes, may but no convincing scenarios are provided where it _does_ and in a way that would cause real grieve for many users. and we are still talking about defaults (= most sensible/suitable for most users) here, not about good vs. evil behaviour. I repeat that I support the recent proposal by richard to change the default as described. options it exposes, since it's a command line tool. In this case, it would not be unlike changing the default behavior of the Unix rm command to implicitly include the -f option. _that_ is the default in unix (no questions asked). but it's aliased to `rm -i' for normal user accounts. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/15/12 05:26, Joe Mistachkin wrote: My opinion is that backward compatibility should be retained because various people, including several that may not be involved in this discussion, have existing scripts and other automation that relies upon the current behavior. I'm going to speculate that this will affect very few users in the end (and that they'll survive the change without any problems). Do you actually know of any such cases; if so, would you care to explain the work-flow so we get a better understanding of how they are used (more importantly; so we understand how dangerous such a change would be)? In particular, with the proposed change there's no chance of loss of data as I see it. If the scripts fail, the data is still in the repository (again, no one is suggesting fossil blindly remove files). ..while the proposed change will affect many users (in a positive way). (And yes, I do believe that numbers matter. Not entirely, but sufficiently in this case). 1. Retain the existing behavior for all current commands and aliases. It is far too dangerous to change the DEFAULT semantics of these commands now. I don't agree. Of those I have introduced to fossil most of them have complained about the mv/rm command (I think I've found a bug..). One user in particular has never used SCM's before, so he had no preconceived ideas with regards to SCM's. I know how bad anecdotal evidence is in a universal discussion, but I firmly believe my friends and acquaintances are representative enough for me to make a somewhat valid extrapolation. If every user that I introduce to fossil who uses mv or rm comes to me and says they've found a bug, then I feel it's a problem in fossil, not the users. Not to mention the times it's been brought up on the mailing list and other Internet-forums. 2. Add entirely new commands named relocate (for mv) and obliterate (for rm) that will perform actions on the repository itself as well as the file system. Obliterate has shun connotations for those who have used Perforce, If we go with different names, I would prefer another name for the commands. mv and rm are good, because they make sense in Unix. As a new user, I would have expected relocate and obliterate to be a database only operations. For me, then rather than two commands which has behavior which doesn't make sense, we'd have four. I vote no, and again reaffirm my vote for the suggestion drh wrote last night (local time). -- Kind regards, Jan Danielsson ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/15/12 11:24, j. v. d. hoff wrote: [---] and I do not buy the it'll be really dangerous for so many people prophecy. of course, if one really tries hard one can manage to get things messed up on disk (change lots of things in tracked files, but don't ever check in (clever) and then decide to stop tracking the files and issue 'fossil rm' assuming the files are left alone on disk and only then discover they were not). the transition period should guarantee that this will not evelove into a real-world problem I'd say. *nods in major agreement* -- Kind regards, Jan Danielsson ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sat, 15 Dec 2012 12:52:34 +0100 Jan Danielsson jan.m.daniels...@gmail.com wrote: Obliterate has shun connotations for those who have used Perforce, If we go with different names, I would prefer another name for the commands. Similar here...I know 'obliterate' from darcs and the explanation is: darcs obliterate - Obliterate completely removes recorded patches from your local repository. The changes will be undone in your working copy and the patches will not be shown in your changes list anymore. Beware that you can lose precious code by obliterating! I vote no, and again reaffirm my vote for the suggestion drh wrote last night (local time). I also stay behind my vote for changes proposed by Richard before changing his mind. Sincerely, Gour -- A self-realized man has no purpose to fulfill in the discharge of his prescribed duties, nor has he any reason not to perform such work. Nor has he any need to depend on any other living being. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sat, 15 Dec 2012 01:52:11 +0100, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 12/15/12 01:06, Eric wrote: [---] 4) I am not criticizing people, merely what they say. I see evidence that they don't get where I'm coming from because they have only an incomplete idea of what this is all about. 5) SCM stands for Software Configuration Management which is not the same thing as version control. Look it up. You will possibly hate it, but if you ever write software that can affect real lives or large amounts of money you will need to know about it. So SCM defines how rm and mv should behave? Oh for crying out loud! Of course it doesn't. That's the original subject of this thread, and behind all the nonsense it's beginning to look like there might be a sensible resolution. But there was so much nonsense here before I ever posted in this thread that I felt the need to pick up on all the things being claimed with no reason or an incorrect reason, so many that a general statement seemed better than a whole lot of little nit-picks which wouldn't make my real point anyway. Get it? There is more than one topic of conversation here and, I'm sorry, but you do seem to be wilfully misunderstanding this. And in order to take part of these definitions, to gain a complete idea of what this is all about, one needs to write software which affects real lives or large amounts of money? Well, I develop programs which *very* much can affect real lives, and large amounts of money is involved. No one has invited me to any secret organization where the *true* definition of SCM is revealed. You have a VCS, and rules about when and if you can check in things that won't build. You have rules about when you should branch and how branches should be labelled. You have a proper change-management system with adequate record-keeping. You have a test suite and can prove it's coverage and that it has been used. You have a bug-tracking system. You have proper backups and a disaster recovery plan for your _development_ systems. You can say how some part of your system behaved a year ago, and how it behaves now, and why it is different, and if there is an unauthorized difference you can find out who was responsible. If not I don't want my real life or my real money anywhere near your software! SCM is not a religion or a secret as you seem to think I said, it is a set of engineering and business disciplines to provide accountability, verifiability, traceability and control for the development process. Those who just want to use Fossil for their own development will not want to know about any of that, and that's fine, but as far as I know Fossil wants to be able to live in that sort of environment, so many of the changes people want should not happen. So they do need to know that there may be reasons beyond their current knowledge. The only stupidity (and I did not use that word) is from those who do not believe there is anything beyond their current knowledge, and who feel insulted when told there is something they don't know. Sorry, but I think you're being silly. You don't know any more about these things than anyone else here. Beg to differ, though not necessarily with respect to _everybody_ else. (Not providing CV or references though). Calling you an ass was a little harsh, but at the same time, you are stating that others are inferior to you, yet you present nothing of substance to back it up. I understand why people are get a little annoyed. But do you now understand why I am so exasperated? You seem to be indicating that there's some exact definitions of an SCM which will resolve the rm/mv issue once and for all. Rather than to talk about affecting real lives and how much money is involved and other irrelevant nonsense, post those exact SCM definitions which are relevant to the mv/rm issues and we can judge that information directly. Once again, that issue was only the trigger for a lot of (in my view) nonsense and my reaction to it. And I am still exasperated! Eric -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, 14 Dec 2012 20:46:22 -0700, Chad Perrin c...@apotheon.net wrote: Why do people feel insulted when it is suggested that they don't know everything? I know what SCM is, you condescending ass. I believe you, but there are some here who don't know, and the message is for everybody. And I did say Well, I had to pick one message to answer. Instead of thinking this bit isn't for me you feel insulted and start being rude. Or rather, continue being rude. I do not understand this behaviour. Eric -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sat, Dec 15, 2012 at 05:15:17PM +, Eric wrote: On Fri, 14 Dec 2012 20:46:22 -0700, Chad Perrin c...@apotheon.net wrote: Why do people feel insulted when it is suggested that they don't know everything? I know what SCM is, you condescending ass. I believe you, but there are some here who don't know, and the message is for everybody. And I did say Well, I had to pick one message to answer. Instead of thinking this bit isn't for me you feel insulted and start being rude. Or rather, continue being rude. I do not understand this behaviour. Your implication that anyone who disagrees with you must not know anything implicitly includes me and everyone else here who disagrees with you. If you are not aware of this fact, I recommend you reread your emails before sending next time. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/15/2012 03:52 AM, Jan Danielsson wrote: On 12/15/12 05:26, Joe Mistachkin wrote: My opinion is that backward compatibility should be retained because various people, including several that may not be involved in this discussion, have existing scripts and other automation that relies upon the current behavior. I'm going to speculate that this will affect very few users in the end (and that they'll survive the change without any problems). Do you actually know of any such cases; if so, would you care to explain the work-flow so we get a better understanding of how they are used (more importantly; so we understand how dangerous such a change would be)? In particular, with the proposed change there's no chance of loss of data as I see it. If the scripts fail, the data is still in the repository (again, no one is suggesting fossil blindly remove files). Throughout all of this, I've been a little at a loss how data loss is _ever_ possible with drh's proposed mechanism. According to the latest proposal, the file will be removed from disk iff it's removed from fossil AND is unchanged from its state in the last checkin. So... the user has checked in this file. It's managed. It's in the fossil repo. They decide they don't want it, and fossil rm it. Fossil removes it from the checkin and from the disk...oh crud, they did want it after all! Well, it's still in the previous checkin, isn't it?? When is it _ever_ going to happen that the user's going to actually lose data under this scenario? ..while the proposed change will affect many users (in a positive way). (And yes, I do believe that numbers matter. Not entirely, but sufficiently in this case). 1. Retain the existing behavior for all current commands and aliases. It is far too dangerous to change the DEFAULT semantics of these commands now. I don't agree. Of those I have introduced to fossil most of them have complained about the mv/rm command (I think I've found a bug..). One user in particular has never used SCM's before, so he had no preconceived ideas with regards to SCM's. I know how bad anecdotal evidence is in a universal discussion, but I firmly believe my friends and acquaintances are representative enough for me to make a somewhat valid extrapolation. If every user that I introduce to fossil who uses mv or rm comes to me and says they've found a bug, then I feel it's a problem in fossil, not the users. Not to mention the times it's been brought up on the mailing list and other Internet-forums. 2. Add entirely new commands named relocate (for mv) and obliterate (for rm) that will perform actions on the repository itself as well as the file system. Obliterate has shun connotations for those who have used Perforce, If we go with different names, I would prefer another name for the commands. mv and rm are good, because they make sense in Unix. As a new user, I would have expected relocate and obliterate to be a database only operations. For me, then rather than two commands which has behavior which doesn't make sense, we'd have four. I vote no, and again reaffirm my vote for the suggestion drh wrote last night (local time). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, Dec 14, 2012 at 08:26:33PM -0800, Joe Mistachkin wrote: My opinion is that backward compatibility should be retained because various people, including several that may not be involved in this discussion, have existing scripts and other automation that relies upon the current behavior. Backward compatibility should be broken sometimes. It is a decision that should be undertaken only with great care, but it should sometimes be undertaken. That's an important part of how software improves over time. Whether the current behavior being ideal or not is an entirely different debate. My ideas on this issue are as follows: 1. Retain the existing behavior for all current commands and aliases. It is far too dangerous to change the DEFAULT semantics of these commands now. I disagree. A careful, measured approach to changing default behavior with a clear, unambiguous understanding of when and how things change mitigates the potential for problems. The major version number in semantic versioning practice, in fact, exists specifically for the purpose of indicating that backward compatbility has been broken. Thus, changes to default behavior that break backward compatibility should only be released in major version number releases (and their release candidates, if applicable), additions to the functionality of the software without destructive changes should only be released on major and minor version numbers, and fixes can be released on major, minor, or revision version numbers. This way, when you consider an upgrade, you know what you're getting into just by looking at the number. If you are not ready for changes in default behavior, don't upgrade to the next major version number. There is no good argument for software defaults to be set in stone for all time. Just use reasonable caution when releasing changes to default behavior. 2. Add entirely new commands named relocate (for mv) and obliterate (for rm) that will perform actions on the repository itself as well as the file system. Apart from the fact that these terms are already used elsewhere with distinctly different meanings (thus duplicating the problem that already exists), it does not solve the problem that already exists. 5. Optionally, add a -f/-filesystem option to the existing mv/rm commands if there is consensus on this point. This new option will cause the exact same behavior as the new commands, including the errors as described above. Honestly, if the repurposing of the rm and mv commands is not to happen (though it should), this is the only suggestion that I think really makes sense for the project. A -f (--force, probably, rather than --filesystem) is better than `relocate` and `obliterate` commands as you have suggested, I think. Of course, the problem of surprising behavior for `rm` and `mv` would still apply in that case. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sat, Dec 15, 2012 at 03:03:26AM -0800, Joe Mistachkin wrote: j. v. d. hoff wrote: POLS comes again to mind. The Principle of Least Surprise is not static. Changing the current behavior would be a huge (and potentially unpleasant) surprise for those who are very actively using Fossil now. It shouldn't be a surprise, as the migration is currently proposed, unless all those users never upgrade Fossil SCM between now and the some- future-time final change in functionality, thanks to the behavior migration warnings and other indications (including, presumably, a major version number change) that should apply along the way. I can tell you that I _was_ surprised (being also a user of svn and hg) when I installed fossil quickly read through the help (ah yes, ci, add, pull, push, rm, mv, stat, log -- default naming scheme for default tasks), Of course, there are much bigger differences between Fossil and those other systems than the semantics of mv and rm. . . . most of which are not *bad* differences like this one. and I do not buy the it'll be really dangerous for so many people prophecy. Obviously, I do buy it. Breaking compatibility is generally bad. It's even worse when other _software_ (i.e. not humans) may depend on the current semantics. The surface area of Fossil is the set of command line options it exposes, since it's a command line tool. In this case, it would not be unlike changing the default behavior of the Unix rm command to implicitly include the -f option. Should all software never ever break any backward compatibility ever, just because something may be automated somewhere by someone who will never pay attention to warnings given by the software itself or will skip many intermediate versions before upgrading to a new, post-change version? Should we always plan changes only for the sake of the most irresponsible users? What are your criteria for allowing something to change? What if all rm did was give you a warning saying You need to issue the command wakka_ wakka_dingbat_eliminate_this_file_from_the_repository because the rm command is only a documentation helper!? Would you say we should never change the behavior of rm and leave everyone stuck with wakka_wakka_ dingbat_eliminate_this_file_from_the_repository forever after to serve the demands of backward compatibility? If your answer is No, of course not! That's just silly! then we've reached a point of agreement where we have established that sometimes breaking backward compatibility is a good idea. All that remains at that point is negotiating the specific cutoff point between good idea and bad idea. If your answer is Yes! on the other hand, I think you and I have absolutely zero common ground for discussion of the matter at all, because wakka_wakka_dingbat_eliminate_this_file_from_the_repository with the described `rm` behavior referring to it is intentionally meant to be regarded as silly beyond reason. If to you it's perfectly reasonable to leave it as-is, we aren't even speaking the same language. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Chad Perrin wrote: If you are not ready for changes in default behavior, don't upgrade to the next major version number. There is no good argument for software defaults to be set in stone for all time. Just use reasonable caution when releasing changes to default behavior. That is somewhat difficult in my case as I typically run trunk (or very close to it) to use the new/modified features I've been adding. It shouldn't be a surprise, as the migration is currently proposed, unless all those users never upgrade Fossil SCM between now and the some- future-time final change in functionality, thanks to the behavior migration warnings and other indications (including, presumably, a major version number change) that should apply along the way. That is an exceptionally bad assumption. We've had users that did not upgrade over a year. Subsequently, they would sometimes notice a significant behavioral change and report it to us. If rm suddenly started deleting files, I suspect that could induce panic, even if the action could be undone. .. . . most of which are not *bad* differences like this one. Good and bad are very subjective, as this thread proves. Should all software never ever break any backward compatibility ever, just because something may be automated somewhere by someone who will never pay attention to warnings given by the software itself or will skip many intermediate versions before upgrading to a new, post-change version? Attempting to demonize people for relying on the current behavior seems to be in poor taste. Should we always plan changes only for the sake of the most irresponsible users? Being openly hostile to users (i.e. by calling them irresponsible) is also in poor taste. Software that is openly hostile to its user base does not end up being too popular. Finding examples of this is within the industry is left as an exercise for the reader. If to you it's perfectly reasonable to leave it as-is, we aren't even speaking the same language. I'm not sure if this is an attempt to insult me or not; however, I'll just assume that it is not. Not changing something in an incompatible way is always a reasonable choice. I think we'll have to agree to disagree on this. There are several other problems with changing the current behavior: 1. The opposite of add is remove. The add command does not modify the file system. It merely records something to be done for the next commit. Similarly, the current remove command does this as well. 2. If the mv and rm commands were to be changed to perform some action during commit, that would be very confusing as commit should only modify the repository. On the other hand, if the mv and rm commands were to perform their file system actions prior to commit, would revert need to bring the previous files back to life? That does not make sense. 3. Related to the previous problem... Think about very large files. If the rm command removes a very large file from the file system and later it needs to be restored, that is a whole lot of file I/O (potentially up to several GB). This can be very hard on machines that are using SSD as their primary storage. 4. What happens if a user tries to rm a file that does not exist in the repository? Presumably, it would just issue an error message? 5. What happens if a user tries to rm a file that has been shunned at some point? 6. What happens if a user tries: fossil rm . ? 7. What happens if a user needs to add all files in the directory except for generated files (i.e. fossil add .)? After that point, normally *I* would rm the extra files; however, I do not want them deleted from the file system. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/16/12 00:36, Joe Mistachkin wrote: [---] 2. [---] On the other hand, if the mv and rm commands were to perform their file system actions prior to commit, would revert need to bring the previous files back to life? That does not make sense. Why not? $ fossil rm foo.txt foo.txt deleted from filesystem, and marked for removal in the repository. ...ops, wrong file.. $ fossil status foo.txt DELETED $ fossil revert foo.txt ..brings back the file in the filesystem, and unmarks file for removal.. Why doesn't that make sense? 3. Related to the previous problem... Think about very large files. If the rm command removes a very large file from the file system and later it needs to be restored, that is a whole lot of file I/O (potentially up to several GB). This can be very hard on machines that are using SSD as their primary storage. First, I feel you're inventing problems to make arguments in order to exclude features which address real world issues. (A little like the script issue brought up earlier). Second (slightly off-topic), What's the problem with SSD and large files? I have been using SLC SSD's since 2007, and since 2008 almost exclusively mixed SLC and MLC SSD's on both servers and clients. On two machines I regularly handle multi-GB files, and have not encountered any issues which I haven't encountered with spinning-platter disks. I fail to see why I would suddenly start having issues with large files because I'm using fossil on SSD:s? (which, I'll admit, I have not). Anyway, even with the current behavior, one could fossil rm a few GB-sized files, then remove the files from the filesystem, and later realize one was in the wrong directory or something, so even with the current situation one could end up needing to wait a while for a reverted undelete. ...and also, when you revert a deleted file, doesn't fossil need to scan through the entire file to see if it has changed? If you revert a multi-GB file, you'll still need to spend some time waiting for it, no? There are lots of ways you can screw up, but the important thing is that you can recover. I also think we have to assume that the normal case is that people won't screw up, and assume that normally people double check before they do something. (Wasn't that one of the insults directed at those of us who want real mv/rm? That we just blindly do things without thinking things through? Ironic twist (yes, I know you weren't the one to say it, but someone else did)). Plus, if you know you're setting yourself up for such a situation, then don't use the real rm; use the command which has retained the old behavior (unmanage, for instance). And finally, if you're worried about performance, try working with the netbsd repository. IMHO, there are far more common everyday optimizations which need to be done looong before we worry about the odd several GB data was deleted by mistake from a working tree.. 4. What happens if a user tries to rm a file that does not exist in the repository? Presumably, it would just issue an error message? Yes. (I recommend you read through the threads; some of the issues you raise have been discussed previously). 5. What happens if a user tries to rm a file that has been shunned at some point? What's the current behavior, and why would it need to differ? 6. What happens if a user tries: fossil rm . ? What happens them you type: $ rm . .. ? And what happens in other SCM's which support real rm? 7. What happens if a user needs to add all files in the directory except for generated files (i.e. fossil add .)? After that point, normally *I* would rm the extra files; however, I do not want them deleted from the file system. You appear to be assuming that the suggestion is to change the behavior of rm/mv and not retain the current behavior in any shape or form. The suggestion which finally seemed to have pleased (mostly) both sides was: Stage 1: (a) fossil rm -f deletes from disk (if it is safe to do so) (b) fossil rm works as currently, but prints a warning message that it will delete from disk in a future release. (c) fossil delete works as currently (d) fossil unmanage added as an alias for fossil delete Stage 2 (after a stage 1 has been released for a while): (e) fossil rm works just like fossil rm -f So, you'll be able to continue doing exactly what you are doing sans s/rm/unmanage/. Everyone gets the behavior they want; others who previously opposed real mv/rm seem to think that the latest suggestion was a good compromise. For a brief moment, I thought that both sides getting what they want would be the end of it.. How come all these points you listed aren't issues with other source management systems which have real rm/mv? -- Kind regards, Jan Danielsson ___
Re: [fossil-users] why does `fossil rm' not do the real thing?
Jan Danielsson wrote: First, I feel you're inventing problems to make arguments in order to exclude features which address real world issues. (A little like the script issue brought up earlier). Straw man argument. Five yard penalty, still first down. Second (slightly off-topic), What's the problem with SSD and large files? I have been using SLC SSD's since 2007, and since 2008 almost exclusively mixed SLC and MLC SSD's on both servers and clients. On two machines I regularly handle multi-GB files, and have not encountered any issues which I haven't encountered with spinning-platter disks. I fail to see why I would suddenly start having issues with large files because I'm using fossil on SSD:s? (which, I'll admit, I have not). The point here is wear-and-tear on the SSD, which have a finite limit of the number of bytes they can write during their useful lifetime. Sorry if this point was not clear in my previous response. ...and also, when you revert a deleted file, doesn't fossil need to scan through the entire file to see if it has changed? If you revert a multi-GB file, you'll still need to spend some time waiting for it, no? I was not referring to the performance, see above. There are lots of ways you can screw up, but the important thing is that you can recover. I also think we have to assume that the normal case is that people won't screw up, and assume that normally people double check before they do something. (Wasn't that one of the insults directed at those of us who want real mv/rm? That we just blindly do things without thinking things through? Ironic twist (yes, I know you weren't the one to say it, but someone else did)). I just think there should be a clear division between Fossil commands that interact with the file system and those that do not. I expect the clean and revert commands to deal with modifying files in the file system; however, I would not expect the add, mv, and rm commands to do that. Plus, if you know you're setting yourself up for such a situation, then don't use the real rm; use the command which has retained the old behavior (unmanage, for instance). Bike shedding. The new command, say realrm (or whatever) could just as easily be made to perform the semantics you desire instead of breaking backward compatibility by modifying existing commands. Yes. (I recommend you read through the threads; some of the issues you raise have been discussed previously). Frankly, I've been trying to avoid getting involved in this discussion at all. If people really want mv and rm to perform file system operations, they can already: 1. Write a wrapper script that performs the operations. 2. Customize their local Fossil binaries to include the necessary code. Also, I have read most of the messages in this thread; however, I think it may be next to impossible to read them all. I do not even know how many messages there are in total. Stage 1: (a) fossil rm -f deletes from disk (if it is safe to do so) (b) fossil rm works as currently, but prints a warning message that it will delete from disk in a future release. (c) fossil delete works as currently (d) fossil unmanage added as an alias for fossil delete Stage 2 (after a stage 1 has been released for a while): (e) fossil rm works just like fossil rm -f I agree with (1a), (1c), and (1d). I disagree with all the others, especially (2e). How come all these points you listed aren't issues with other source management systems which have real rm/mv? Frankly, I don't use the those other systems on a regular basis and I really do not care what they do. Sorry. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/15/2012 06:28 PM, Joe Mistachkin wrote: Jan Danielsson wrote: First, I feel you're inventing problems to make arguments in order to exclude features which address real world issues. (A little like the script issue brought up earlier). Straw man argument. Five yard penalty, still first down. Second (slightly off-topic), What's the problem with SSD and large files? I have been using SLC SSD's since 2007, and since 2008 almost exclusively mixed SLC and MLC SSD's on both servers and clients. On two machines I regularly handle multi-GB files, and have not encountered any issues which I haven't encountered with spinning-platter disks. I fail to see why I would suddenly start having issues with large files because I'm using fossil on SSD:s? (which, I'll admit, I have not). The point here is wear-and-tear on the SSD, which have a finite limit of the number of bytes they can write during their useful lifetime. Sorry if this point was not clear in my previous response. So, you're saying that we wouldn't want to remove files from disk when they're removed from the repository, because that action--which probably wouldn't be a daily occurrence, and in my own personal use is a once-every-week-or-so kind of thing--would be potentially bad for SSDs? I'm sympathetic to the idea that software should be written with a certain efficiency or hardware-awareness in mind, but this seems like a bit of a stretch. ...and also, when you revert a deleted file, doesn't fossil need to scan through the entire file to see if it has changed? If you revert a multi-GB file, you'll still need to spend some time waiting for it, no? I was not referring to the performance, see above. There are lots of ways you can screw up, but the important thing is that you can recover. I also think we have to assume that the normal case is that people won't screw up, and assume that normally people double check before they do something. (Wasn't that one of the insults directed at those of us who want real mv/rm? That we just blindly do things without thinking things through? Ironic twist (yes, I know you weren't the one to say it, but someone else did)). I just think there should be a clear division between Fossil commands that interact with the file system and those that do not. I expect the clean and revert commands to deal with modifying files in the file system; however, I would not expect the add, mv, and rm commands to do that. Frankly speaking, I'd expect the opposite, but more than anything else I'd expect that the documentation can tell me what commands do what. And, again, if the user issued the 'fossil rm' and it removed the file from the repo and from disk, couldn't the user just pull it back out of their last checkin, if for some reason they wanted to unmanage it but retain it? Or, put another way, how often have you wanted to delete a file from a repo, but not delete it from disk? Or move it within the repo, but not wanted to move it on disk? Is there any practical reason you're opposed to this minor change in how the command works, or is it an adherence to a principle of making as few incompatible changes as possible? Plus, if you know you're setting yourself up for such a situation, then don't use the real rm; use the command which has retained the old behavior (unmanage, for instance). Bike shedding. The new command, say realrm (or whatever) could just as easily be made to perform the semantics you desire instead of breaking backward compatibility by modifying existing commands. Yes. (I recommend you read through the threads; some of the issues you raise have been discussed previously). Frankly, I've been trying to avoid getting involved in this discussion at all. If people really want mv and rm to perform file system operations, they can already: 1. Write a wrapper script that performs the operations. 2. Customize their local Fossil binaries to include the necessary code. Also, I have read most of the messages in this thread; however, I think it may be next to impossible to read them all. I do not even know how many messages there are in total. Stage 1: (a) fossil rm -f deletes from disk (if it is safe to do so) (b) fossil rm works as currently, but prints a warning message that it will delete from disk in a future release. (c) fossil delete works as currently (d) fossil unmanage added as an alias for fossil delete Stage 2 (after a stage 1 has been released for a while): (e) fossil rm works just like fossil rm -f I agree with (1a), (1c), and (1d). I disagree with all the others, especially (2e). How come all these points you listed aren't issues with other source management systems which have real rm/mv? Frankly, I don't use the those other systems on a regular basis and I really do not care what they do. Sorry. -- Joe Mistachkin
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/16/12 03:28, Joe Mistachkin wrote: First, I feel you're inventing problems to make arguments in order to exclude features which address real world issues. (A little like the script issue brought up earlier). Straw man argument. Five yard penalty, still first down. Still, I think I'm right. I don't think any of the issues you've brought up as potential serious issues so far are actual problems. But I know for sure that the current mv/rm behavior is not what many people (who have voiced their opinion) expect, and I'm fairly certain that the change would overall be for the better. Second (slightly off-topic), What's the problem with SSD and large files? I have been using SLC SSD's since 2007, and since 2008 almost exclusively mixed SLC and MLC SSD's on both servers and clients. On two machines I regularly handle multi-GB files, and have not encountered any issues which I haven't encountered with spinning-platter disks. I fail to see why I would suddenly start having issues with large files because I'm using fossil on SSD:s? (which, I'll admit, I have not). The point here is wear-and-tear on the SSD, which have a finite limit of the number of bytes they can write during their useful lifetime. Sorry if this point was not clear in my previous response. Oh, ok. # atactl wd0 smart status id value thresh crit collect reliability description 9 1000 no online positivePower-on hours count 28691 12 1000 no online positiveDevice power cycle count 312 192 1000 no online positivePower-off retract count165 225 2000 no offline positiveLoad/unload cycle count 227574 232 100 10 yes online positiveUnknown0 233 990 no online positiveUnknown0 ..and this is my second-most tortured drive. (An Intel-drive, in case anyone wants to look up the Unknown id's). The wear and tear in this context is (another) completely bogus argument. Unless one buys some broken-by-design drive (but again, one can just as well do that with a spinning-platter disk, so there's still no valid point). There are lots of ways you can screw up, but the important thing is that you can recover. I also think we have to assume that the normal case is that people won't screw up, and assume that normally people double check before they do something. (Wasn't that one of the insults directed at those of us who want real mv/rm? That we just blindly do things without thinking things through? Ironic twist (yes, I know you weren't the one to say it, but someone else did)). I just think there should be a clear division between Fossil commands that interact with the file system and those that do not. I expect the clean and revert commands to deal with modifying files in the file system; however, I would not expect the add, mv, and rm commands to do that. 1) Fossil does file operations in the working directory regardless. The working directory isn't equivalent to the filesystem; in abstract terms, I see the working directory as the glue between the filesystem and the repository. The working directory is special; it's a place where fossil does its magic. I don't see why this needs to exclude mv and rm. In fact, I would expect fossil to manage (including mv/rm) the files in the working directory which are under version control. 2) Even looking past #1; without some kind of relevant end-game, what reason is there to have such a goal? I've only read We need to separate them, because we need to separate them so far, but no one has explained why it would be more important that The Principle of Least Surprise for new users. 3) There are other places in fossil which violate this strict separation idea. I don't see any noise about them. Again, I think it's a bogus argument from start, so I don't want any noise about any other issues. I can appreciate abstract separations, but in this case I hardly think it applies. Especially in the face of making fossil more intuitive I think these made up separations are just nonsense. Plus, if you know you're setting yourself up for such a situation, then don't use the real rm; use the command which has retained the old behavior (unmanage, for instance). Bike shedding. Oh, we reached that point 50 posts ago. :) The new command, say realrm (or whatever) could just as easily be made to perform the semantics you desire instead of breaking backward compatibility by modifying existing commands. Yes, but - as has been written so many times now that it's not even funny any longer: rm/mv has a canonical behavior, and new users continue to be surprised by the current behavior. We want to adjust rm/mv according to The Principle of Least Surprise. I think the vast majority of fossil users will think Oh, so they changed it to what I first expected rather than panic!. Yes. (I recommend you read through the threads;
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/14/12 00:23, Richard Hipp wrote: But, should there be an opt-in option to also make the disk changes? Yes -- definitely. -- Kind regards, Jan Danielsson ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/14/12 00:56, Nolan Darilek wrote: Who would have guessed that something as simple as having rm remove the file from disk would prompt opponents to: * claim that I want Fossil to be like Git. * Call me lazy. * Insult my intelligence by claiming that I don't know what a VCS is or should do. Done with this thread. Keep it classy, detractors. 100% agree. I must say, I'm not quite as fond of the fossil community as I once was. I have no interest in being insulted further. -- Kind regards, Jan Danielsson ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, 14 Dec 2012 10:55:50 +0100 Jan Danielsson jan.m.daniels...@gmail.com wrote: I must say, I'm not quite as fond of the fossil community as I once was. I have no interest in being insulted further. That's pity that immature people are chasing away older members. :-( Sincerely, Gour -- Thus the wise living entity's pure consciousness becomes covered by his eternal enemy in the form of lust, which is never satisfied and which burns like fire. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, Dec 14, 2012 at 12:23 AM, Richard Hipp d...@sqlite.org wrote: So Altu and Eric (and also Joe Mistachkin on a back-channel) have pretty much convinced me at this point to keep the current behavior of fossil rm and fossil mv. I'm happy to read this. Thank you. I had refrained to chime in the discussion so far, because I was not sure about how to articulate my point of view. Now I think the point is, it is good practice that processes responsible for creating/opening/locking a resource must be the same responsible for deleting/closing/unlocking them. If I manually create a file, it must be me to manually delete it when I don't need it anymore. It must not be deleted as a side effect of some other thing. And no, saving a few keystrokes does not balance this. Cheers P. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Richard Hipp wrote: [...] But, should there be an opt-in option to also make the disk changes? Perhaps fossil rm abc.txt just removes abc.txt from configuration management, but fossil rm -f abc.txt also removes it from disk? Yes, please. (Particularly with fossil mv; refactoring large numbers of files becomes annoyingly fiddly without it.) And/or should there be a warning printed: File abc.txt removed from management but unchanged on disk just to give a heads-up to newcomers who expect different behavior? I think this is also a good idea. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true. --- Master Li Kao, │ _The Bridge of Birds_ signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, Dec 13, 2012 at 11:08:04PM +, Eric wrote: On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com wrote: In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit. Well, yes, that is the way I do it too. I suspect that there are some who do not review their changes before commit, and that many of those commit way too often, essentially treating their VCS as a backup method. This of course leads to junk, non-functional checkins, followed by an unhealthy interest in rebase-like functionality. On another note, people are saying things like there is a certain behaviour that is expected without saying why it is expected. The main reasons seem to be that other VCS's do it and that it saves time. The first is irrelevant and the second, in my opinion, a case of people knowing the price of everything and the value of nothing. I think this thread has served to highlight the number of people here who want Fossil to be something other that what it set out to be, and don't actually know what SCM means. It doesn't surprise me that they have caused some over-the-top reactions. I review changes before committing, and I don't just treat a VCS as a backup method. I also believe default behavior should be for an `rm` command to do what it says on the tin, in the most convenient and unsurprising manner possible, because computers and the software running on them are supposed to automate away the mind-numbing drudgery of a rigid series of steps that must be taken regularly to achieve common, conceptually simple tasks -- not add redundancy to the actions that must be taken to maintain workflow. I prefer a `fossil rm` command that removes from disk as well, but I do not fit the description your maliciously insulting description of the evils of such obviously inferior people. . . . and you're an ass. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote: This is the classical divide between pragmatists (I want to get my job with with minimal pain so I can go home a play ball with my son) versus the idealists (source code management means doing x, y and z and no more and no less and I'm sorry that it will take you twice as long to do your job right *grin*). Fossil is caught between the messy world of the pragmatists and the nice tidy world of the idealists. There is no one right way to do it. One group or the other will be disappointed. I don't think that's all there is to it. It isn't really fair to those who prefer automation of the full set of rm tasks to suggest they necessarily lack a sense of the idea, or to those who oppose that automation to suggest they lack a sense of pragmatism. I think that the two sides of this discussion are more sophisticated and complex than that, with several different types of argument being possible and presented on each side. The major argument types I have seen so far are: for rm automation| against rm automation --|-- idealist (Unix way) | idealists (airbags way) pragamtists (POLS way) | pragmatists (backward compat) trolls (haven't noticed any) | trolls (NIH and you're dumb) If you know of any trollish argument forms on the pro-automation side, please feel free to point them out. I may be suffering some confirmation bias in this case. Anyway, my explanations of the various arguments, as I have noticed them, follow. * Unix way idealists: When you tell it to do something, it damned well does it. * airbags way idealists: When you tell it to do something that might be accidentally applied in an unintentionally destructive manner by an incautious user, it should second-guess your intentions and try to convince you to do things differently, on the assumption that is not what you wanted. * POLS pragmatists: When you issue a command that seems like it should perform a given task, you expect it to perform the whole task, and not only part of it. Tool design should account for that. * backward compat pragmatists: This is how it has been done so far, establishing a set of expectations particular to long-time users and the automation scripts they have written that rely on the behavior in question. We should not change the tool's behavior to violate those ingrained expectations because there may be backward incompatibility problems. * NIH trolls: You're trying to turn Fossil into Git! Stop it! * you're dumb trolls: Obviously you are all too stupid to understand the benefits of keeping things the way they are. You are wrong because you are stupid; you are stupid because you disagree with me. If we could eliminate those troll category participants in the discussion, I think we would get a lot further in sorting this out. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Here's a thought: Let's remove the rm alias and make it just fossil remove. That will eliminate all my objections. When I issue a rm, whether at my shell, or in hg, git, svn, everywhere else but CVS apparently, which is the reason for establishing this expectation, it behaves a certain way. Forget VCSs for a minute. When I issue rm on every Unix implementation on the planet, the file is removed from disk. Unix does not have a remove command about which I have expectations. So let's just ditch fossil rm entirely so that expectation is broken? Then when someone asks for rm to be aliased, we explain that there is a dissonance between how Fossil and just about everything else handles rm, so the non-standard behavior is called remove and nothing more? I have no issues with fossil remove not removing the file from the filesystem, but I will probably almost always hit this fossil rm dissonance. And thus the bikeshed is painted. On 12/14/2012 11:32 AM, Chad Perrin wrote: On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote: This is the classical divide between pragmatists (I want to get my job with with minimal pain so I can go home a play ball with my son) versus the idealists (source code management means doing x, y and z and no more and no less and I'm sorry that it will take you twice as long to do your job right *grin*). Fossil is caught between the messy world of the pragmatists and the nice tidy world of the idealists. There is no one right way to do it. One group or the other will be disappointed. I don't think that's all there is to it. It isn't really fair to those who prefer automation of the full set of rm tasks to suggest they necessarily lack a sense of the idea, or to those who oppose that automation to suggest they lack a sense of pragmatism. I think that the two sides of this discussion are more sophisticated and complex than that, with several different types of argument being possible and presented on each side. The major argument types I have seen so far are: for rm automation| against rm automation --|-- idealist (Unix way) | idealists (airbags way) pragamtists (POLS way) | pragmatists (backward compat) trolls (haven't noticed any) | trolls (NIH and you're dumb) If you know of any trollish argument forms on the pro-automation side, please feel free to point them out. I may be suffering some confirmation bias in this case. Anyway, my explanations of the various arguments, as I have noticed them, follow. * Unix way idealists: When you tell it to do something, it damned well does it. * airbags way idealists: When you tell it to do something that might be accidentally applied in an unintentionally destructive manner by an incautious user, it should second-guess your intentions and try to convince you to do things differently, on the assumption that is not what you wanted. * POLS pragmatists: When you issue a command that seems like it should perform a given task, you expect it to perform the whole task, and not only part of it. Tool design should account for that. * backward compat pragmatists: This is how it has been done so far, establishing a set of expectations particular to long-time users and the automation scripts they have written that rely on the behavior in question. We should not change the tool's behavior to violate those ingrained expectations because there may be backward incompatibility problems. * NIH trolls: You're trying to turn Fossil into Git! Stop it! * you're dumb trolls: Obviously you are all too stupid to understand the benefits of keeping things the way they are. You are wrong because you are stupid; you are stupid because you disagree with me. If we could eliminate those troll category participants in the discussion, I think we would get a lot further in sorting this out. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin c...@apotheon.net wrote: On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote: This is the classical divide between pragmatists (I want to get my job with with minimal pain so I can go home a play ball with my son) versus the idealists (source code management means doing x, y and z and no more and no less and I'm sorry that it will take you twice as long to do your job right *grin*). Fossil is caught between the messy world of the pragmatists and the nice tidy world of the idealists. There is no one right way to do it. One group or the other will be disappointed. I don't think that's all there is to it. It isn't really fair to those who prefer automation of the full set of rm tasks to suggest they necessarily lack a sense of the idea, or to those who oppose that automation to suggest they lack a sense of pragmatism. I think that the two sides of this discussion are more sophisticated and complex than that, with several different types of argument being possible and presented on each side. The major argument types I have seen so far are: for rm automation| against rm automation --|-- idealist (Unix way) | idealists (airbags way) pragamtists (POLS way) | pragmatists (backward compat) trolls (haven't noticed any) | trolls (NIH and you're dumb) If you know of any trollish argument forms on the pro-automation side, please feel free to point them out. I may be suffering some confirmation bias in this case. Anyway, my explanations of the various arguments, as I have noticed them, follow. * Unix way idealists: When you tell it to do something, it damned well does it. * airbags way idealists: When you tell it to do something that might be accidentally applied in an unintentionally destructive manner by an incautious user, it should second-guess your intentions and try to convince you to do things differently, on the assumption that is not what you wanted. * POLS pragmatists: When you issue a command that seems like it should perform a given task, you expect it to perform the whole task, and not only part of it. Tool design should account for that. * backward compat pragmatists: This is how it has been done so far, establishing a set of expectations particular to long-time users and the automation scripts they have written that rely on the behavior in question. We should not change the tool's behavior to violate those ingrained expectations because there may be backward incompatibility problems. * NIH trolls: You're trying to turn Fossil into Git! Stop it! * you're dumb trolls: Obviously you are all too stupid to understand the benefits of keeping things the way they are. You are wrong because you are stupid; you are stupid because you disagree with me. If we could eliminate those troll category participants in the discussion, I think we would get a lot further in sorting this out. Nice analysis Chad! My sincere apologies to anyone insulted by my overly simplistic and arguably unfair comment :) I still want one of these two: Preferred behavior: remove file silently from disk iff the file is controlled and unchanged or if forced with -f. Issue a warning if the file was not removed. Also works for me: don't remove files unless forced with -f. With force all removals on disk happen without any notice. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Le 2012-12-14 12:50, Matt Welland a écrit : On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin c...@apotheon.net mailto:c...@apotheon.net wrote: On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote: This is the classical divide between pragmatists (I want to get my job with with minimal pain so I can go home a play ball with my son) versus the idealists (source code management means doing x, y and z and no more and no less and I'm sorry that it will take you twice as long to do your job right *grin*). Fossil is caught between the messy world of the pragmatists and the nice tidy world of the idealists. There is no one right way to do it. One group or the other will be disappointed. I don't think that's all there is to it. It isn't really fair to those who prefer automation of the full set of rm tasks to suggest they necessarily lack a sense of the idea, or to those who oppose that automation to suggest they lack a sense of pragmatism. I think that the two sides of this discussion are more sophisticated and complex than that, with several different types of argument being possible and presented on each side. The major argument types I have seen so far are: for rm automation| against rm automation --|-- idealist (Unix way) | idealists (airbags way) pragamtists (POLS way) | pragmatists (backward compat) trolls (haven't noticed any) | trolls (NIH and you're dumb) If you know of any trollish argument forms on the pro-automation side, please feel free to point them out. I may be suffering some confirmation bias in this case. Anyway, my explanations of the various arguments, as I have noticed them, follow. * Unix way idealists: When you tell it to do something, it damned well does it. * airbags way idealists: When you tell it to do something that might be accidentally applied in an unintentionally destructive manner by an incautious user, it should second-guess your intentions and try to convince you to do things differently, on the assumption that is not what you wanted. * POLS pragmatists: When you issue a command that seems like it should perform a given task, you expect it to perform the whole task, and not only part of it. Tool design should account for that. * backward compat pragmatists: This is how it has been done so far, establishing a set of expectations particular to long-time users and the automation scripts they have written that rely on the behavior in question. We should not change the tool's behavior to violate those ingrained expectations because there may be backward incompatibility problems. * NIH trolls: You're trying to turn Fossil into Git! Stop it! * you're dumb trolls: Obviously you are all too stupid to understand the benefits of keeping things the way they are. You are wrong because you are stupid; you are stupid because you disagree with me. If we could eliminate those troll category participants in the discussion, I think we would get a lot further in sorting this out. Nice analysis Chad! My sincere apologies to anyone insulted by my overly simplistic and arguably unfair comment :) I still want one of these two: Preferred behavior: remove file silently from disk iff the file is controlled and unchanged or if forced with -f. Issue a warning if the file was not removed. +2 Also works for me: don't remove files unless forced with -f. With force all removals on disk happen without any notice. +1 -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, 14 Dec 2012 10:10:44 -0700, Chad Perrin c...@apotheon.net wrote: Well, I had to pick one message to answer Aaargh! (there should be more as) 1) Telling the operating system to delete a file from disk and telling the VCS that a file which is in the parent commit should not be in the next are two very different actions and I think they should be kept separate. 2) In hindsight perhaps re-using the Unix/Linux command names wasn't such a good idea. Would this thread be so out of hand if it had always been fossil remove? 3) As time has passed I have felt less and less comfortable in this list because there are more and more contributors here who want changes I don't like without providing any real argument at all beyond that some other system does it. So I have introduced that more general issue into this thread with a very specific (though misleading) subject. Sorry but thread-drift is natural (and is the same thing as conversation-drift which has always happened). 4) I am not criticizing people, merely what they say. I see evidence that they don't get where I'm coming from because they have only an incomplete idea of what this is all about. 5) SCM stands for Software Configuration Management which is not the same thing as version control. Look it up. You will possibly hate it, but if you ever write software that can affect real lives or large amounts of money you will need to know about it. Back to the email I am replying to... I prefer a `fossil rm` command that removes from disk as well, but I do not fit the description Quite possibly not, I wouldn't know at this point. your maliciously insulting description of the evils of such obviously inferior people. You have managed to put more venom towards me in those few words than there could ever have been in anything I said, and nothing I said was directed at you explicitly anyway. . . . and you're an ass. Direct gratuitous insult. Well done. Eric -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/15/12 01:06, Eric wrote: [---] 4) I am not criticizing people, merely what they say. I see evidence that they don't get where I'm coming from because they have only an incomplete idea of what this is all about. 5) SCM stands for Software Configuration Management which is not the same thing as version control. Look it up. You will possibly hate it, but if you ever write software that can affect real lives or large amounts of money you will need to know about it. So SCM defines how rm and mv should behave? And in order to take part of these definitions, to gain a complete idea of what this is all about, one needs to write software which affects real lives or large amounts of money? Well, I develop programs which *very* much can affect real lives, and large amounts of money is involved. No one has invited me to any secret organization where the *true* definition of SCM is revealed. Sorry, but I think you're being silly. You don't know any more about these things than anyone else here. Calling you an ass was a little harsh, but at the same time, you are stating that others are inferior to you, yet you present nothing of substance to back it up. I understand why people are get a little annoyed. You seem to be indicating that there's some exact definitions of an SCM which will resolve the rm/mv issue once and for all. Rather than to talk about affecting real lives and how much money is involved and other irrelevant nonsense, post those exact SCM definitions which are relevant to the mv/rm issues and we can judge that information directly. -- Kind regards, Jan Danielsson ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Sat, Dec 15, 2012 at 12:06:02AM +, Eric wrote: 1) Telling the operating system to delete a file from disk and telling the VCS that a file which is in the parent commit should not be in the next are two very different actions and I think they should be kept separate. I'm perfectly fine with there being a way to keep the peformance of these tasks separate, and I doubt anyone else here has a problem with it either. What people actually want is a POLS way to combine them. The suggestion of moving current `rm` behavior to `remove`, and repurposing `rm`, seems like an excellent way to satisfy both needs. I'd be just as happy with a command line option for the current behavior and the default being repurposed as proposed, though some people would evidently be miffed by that even if they insist everyone else use a command line option instead, so the command line option may be a suboptimal solution. Considering nobody's saying the two tasks you identify as distinct should be inextricably linked for all cases renders your objection here entirely irrelevant. 2) In hindsight perhaps re-using the Unix/Linux command names wasn't such a good idea. Would this thread be so out of hand if it had always been fossil remove? Probably not. Then people would just want addition of an `rm` command that does what people are now suggesting it should be repurposed to do. 3) As time has passed I have felt less and less comfortable in this list because there are more and more contributors here who want changes I don't like without providing any real argument at all beyond that some other system does it. So I have introduced that more general issue into this thread with a very specific (though misleading) subject. Sorry but thread-drift is natural (and is the same thing as conversation-drift which has always happened). That's fine. The problem is that there are actually substantive arguments being made that you ignore, or to which your only retorts are (perhaps thinly veiled) insults. 4) I am not criticizing people, merely what they say. I see evidence that they don't get where I'm coming from because they have only an incomplete idea of what this is all about. If you do not mean to insult people directly, you should phrase your statements so that you do not make insulting statements. Case in point: . . . they have only an incomplete idea of what this is all about. Yes, of course, that *must* be it. It could not possibly be the case that anyone who has different priorities than you has a meaningful case for a given preference unless that person is an ignorant dolt. Good work on convincing us that you don't mean to insult anyone while in the same breath implying that the *only* reason anyone disagrees with you is an inability to understand the Sekrit Kno-ledge only the intellectual elite such as yourself could ever comprehend. 5) SCM stands for Software Configuration Management which is not the same thing as version control. Look it up. You will possibly hate it, but if you ever write software that can affect real lives or large amounts of money you will need to know about it. I know what SCM is, you condescending ass. This in no way changes anyone's arguments for a change in the behavior of the version control component of Fossil SCM. Yes, there is indeed a version control component -- an integral component of the whole SCM system. Back to the email I am replying to... On Fri, 14 Dec 2012 10:10:44 -0700, Chad Perrin c...@apotheon.net wrote: . . . and you're an ass. Direct gratuitous insult. Well done. Thank you. Unlike yours, my insult was gratuitous. Yours was the meat of your argument. As such, your argument (such as it was) had the unfortunate character of being fallacious as well as rude. Mine was merely rude, and well deserved by the target. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, Dec 14, 2012 at 08:46:22PM -0700, Chad Perrin wrote: On Sat, Dec 15, 2012 at 12:06:02AM +, Eric wrote: 1) Telling the operating system to delete a file from disk and telling the VCS that a file which is in the parent commit should not be in the next are two very different actions and I think they should be kept separate. I'm perfectly fine with there being a way to keep the peformance of these tasks separate, and I doubt anyone else here has a problem with it either. What people actually want is a POLS way to combine them. The suggestion of moving current `rm` behavior to `remove`, and repurposing `rm`, seems like an excellent way to satisfy both needs. I'd be just as happy with a command line option for the current behavior and the default being repurposed as proposed, though some people would evidently be miffed by that even if they insist everyone else use a command line option instead, so the command line option may be a suboptimal solution. I just saw the reminder of the existence of the `delete` command, and if I had thought of that before composing the quoted email I would have suggested `delete` instead of `remove` here. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
My opinion is that backward compatibility should be retained because various people, including several that may not be involved in this discussion, have existing scripts and other automation that relies upon the current behavior. Whether the current behavior being ideal or not is an entirely different debate. My ideas on this issue are as follows: 1. Retain the existing behavior for all current commands and aliases. It is far too dangerous to change the DEFAULT semantics of these commands now. 2. Add entirely new commands named relocate (for mv) and obliterate (for rm) that will perform actions on the repository itself as well as the file system. 3. For the new relocate command, it should raise an error if the destination file name already exists on the file system or in the repository. 4. For the new obliterate command, it should raise an error if the file has been changed in the current checkout. 5. Optionally, add a -f/-filesystem option to the existing mv/rm commands if there is consensus on this point. This new option will cause the exact same behavior as the new commands, including the errors as described above. P.S. This message is not a reply to any given message on this thread, per se. If you disagree with my ideas, that's fine; however, please keep the discussion civil. Thanks. -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, 13 Dec 2012 08:16:48 +0100, Gour g...@atmarama.net wrote: On Wed, 12 Dec 2012 23:42:29 -0300 Richie Adler richiead...@gmail.com wrote: Sorry, I still think that the intention is to destroy what Fossil has of unique to offer to be able to say that Git or Mercurial it's the same and they should be preferred to Fossil. What's next? Replacing SQLite with individual files? Can you please change your mantra labelling every constructive attempt to change something in Fossil as conspiracy by Git advocates. +1 Thank you. Sincerely, Gour -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, 13 Dec 2012 10:58:29 +0100, Gour g...@atmarama.net wrote: On Thu, 13 Dec 2012 06:49:08 -0300 Richie Adler richiead...@gmail.com wrote: Can you please killfile me and leave me alone? That's not the point 'cause your comments are not polite and disturbing to other Fossil users as you can see... +1 Sincerely, Gour -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/12/12, Themba Fletcher themba.fletc...@gmail.com wrote: to alias 'fossil rm' to 'fossil rm -f'. That is a disaster waiting to happen. If the user in question forgets that they've done that, and then runs a series of commands from someone who *didn't* do that (either cut-n-paste from an answer on the list or the web, as part of a script for doing something, or whatever), they'll wind up removing files that nobody wanted removed. An alias mechanism is fine, but it really shouldn't let users change the behavior of builtin commands. Either aliases should have to have different names, or be invoked by some other mechanism. Both of those sort of defeat the purpose of the rm alias, though. mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, 13 Dec 2012 14:09:46 +0100, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 12/13/12 05:07, Carson Chittom wrote: Nolan Darilek no...@thewordnerd.info 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). well, I dit get it (and that's why I started the thread in the first place): couldn't have summarized the actual question/problem at hand better (including that the apparent phobia that fossil might mercurialized, gittized, or what ever is completely beside the point and the 99.9% (or whatever) use case is what matters here). I'm completely surprised by the level of emotion this seemingly innocuous request/question to sanitize the default behaviour has created. hope people are going to calm down again soon. and I really don't get it that at the very least there could be any disagreement that a `fossil mv' without doing the same to the checkout is not a good default. joerg -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/13/12 05:01, Themba Fletcher wrote: What's next? Replacing SQLite with individual files? Absolutely not, and statements like this do more harm than good because they willfully disregard the point of what is being expressed. The point is not to be alarmist and extreme, as statements like the above are. The point is to establish that there is a certain behavior that is expected, and Fossil does not exemplify that. Sure. But without fossil's deviation from the norm what possible reason would I have to choose it over mercurial or git? I recall a discussion about implementing a ? :-operator in a non-C language a few years back. Some simply suggested why not use '? :'?, and some developers said That's C -- we're not C. So someone posted a convoluted syntax which it seemed like almost everyone hated, but the hard core users said it was ok, because it wasn't C. I don't want decisions about fossil to be made on that basis. If we change this behavior to the better, we'll become more like others, so we can't have it.. Being different isn't of any value if the difference doesn't imply improvement (in the case of mv/rm I think fossil's behavior is inferior to others). Extrapolating make rm and mv behave main-stream to we'll become just like mercurial or git seems to be a little of a stretch to me. I have zero objections to becoming main stream with regards to certain features if it means becoming better. Some of the reasons I use fossil are: I trust SQLite, SSL, I like that it uses HTTP as its clone-protocol, the REMOTE_USER feature, I like the web-ui (with all its features), I like the command line ui (mostly), I like the strict DAG property of the repository, the built in wiki, ticket system, user administration, etc. The fact that I have to perform two operations for something which should only require one is _not_ a reason for me to chose fossil over any other system. But more to the point: Even if I saw any value in the separation, such a feature would still not be a reason for me to chose fossil over any other system. It would have exactly zero bearing. I don't see changing the current rm/mv behavior as removing a selling point of fossil (and frankly speaking, I'm quite surprised to see that it's being treated as such). I see it more limiting the number of replies to the question Ok, so you've brought up the pros with fossil. Could mention some of the cons?. I don't think there are many annoyances with fossil, so the mv/rm behavior is a relatively minor issue in the grand scheme of things, but still -- could we make it do all of the work, not just half of it, I would be pleased and have one less con in my list. -- Kind regards, Jan Danielsson ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
2012/12/13 Jan Danielsson jan.m.daniels...@gmail.com Richie Adler (that is, myself, not Themba Fletcher) wrote: What's next? Replacing SQLite with individual files? Absolutely not, and statements like this do more harm than good because they willfully disregard the point of what is being expressed. The point is not to be alarmist and extreme, as statements like the above are. The point is to establish that there is a certain behavior that is expected, and Fossil does not exemplify that. Sure. But without fossil's deviation from the norm what possible reason would I have to choose it over mercurial or git? I don't see changing the current rm/mv behavior as removing a selling point of fossil (and frankly speaking, I'm quite surprised to see that it's being treated as such). In my particular case, is not. It's the recent flurry of requests to git-ify Fossil what's incensing me. That's why I used hyperbole regarding the SQLite They want the good things about fossil but they want to keep working as if it were Git. I say, if they like Git so much, eat the crow that comes with it. -- o-= Marcelo =-o ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/13/2012 08:40 AM, Marcelo wrote: They want the good things about fossil but they want to keep working as if it were Git. I say, if they like Git so much, eat the crow that comes with it. And that doesn't even make sense, either. If I wanted Git, then I'd use Git, full stop. It's silly telling me that changing this rm behavior is suddenly going to make Fossil so like Git that I'm all like Oh, great, now I've succeeded in my nefarious mission of making everything Git-like! Mine is an EVIL laugh! Next I'll ask for rebase! Making this sort of argument damages the cause because it puts those of us advocating for a thing in a position we aren't necessarily in, so it makes us want to just let the point go. I don't want Fossil to be another Git, but by telling me that I do, I'm suddenly either compelled to stop advocating for *any* change that violates Least Surprise. And hell, my example didn't even *use* Git's behavior to justify my claims and I'm *still* being told that OMG I want to make Fossil like teh gits! I respect the Fossil should be conservative arguments even though I disagree with them, but I'm going to call this exaggeration and hyperbole out on the carpet. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, 13 Dec 2012 08:54:25 -0600 Nolan Darilek no...@thewordnerd.info wrote: Making this sort of argument damages the cause because it puts those of us advocating for a thing in a position we aren't necessarily in, so it makes us want to just let the point go. Fortunately, Richard is mature person... Sincerely, Gour -- Whatever action a great man performs, common men follow. And whatever standards he sets by exemplary acts, all the world pursues. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
FWIW, I am following this thread with great interest. I think I understand the various points of view. I think most everybody brings up good points, and I encourage this kind of discussion. My current leanings are to change rm and mv as follows: (1) fossil rm xyx.txt will remove the file xyz.txt from disk if and only if an exact copy of xyz.txt exists under control. If xyz.txt has been modified or if xyz.txt has never been checked in (and the fossil rm is simply to reverse a prior fossil add) then xyz.txt is unchanged. Either way, there are probably no error or warning messages, though I am sympathetic to the argument that there should be a warning message if the file is not deleted from disk. (2) fossil mv abc.txt xyz.txt will rename abc.txt to xyz.txt on disk provided that xyz.txt does not previously exist on disk or if xyz.txt does already exist and its content is identical to abc.txt. If xyz.txt does previously exist and is different from abc.txt (and hence would be overwritten) then the operation just fails out-right with an appropriate error message. It seems to me that the behaviors above are the most intuitive and provide developers with the least amount of surprise. The goal of Fossil (as it should be for any VCS) is to get out of the developer's way and just do the right thing, so that the developer can devote maximum brain-power to working on their application, and expend a minimum number of brain-cycles thinking about Fossil and how to control it. And I think the behaviors outlined above probably best achieve this goal. But I am far from certain of that, so please do continue debating the issue. We want to get this right. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, 13 Dec 2012 10:38:36 -0500 Richard Hipp d...@sqlite.org wrote: (1) fossil rm xyx.txt will remove the file xyz.txt from disk if and only if an exact copy of xyz.txt exists under control. If xyz.txt has been modified or if xyz.txt has never been checked in (and the fossil rm is simply to reverse a prior fossil add) then xyz.txt is unchanged. Either way, there are probably no error or warning messages, though I am sympathetic to the argument that there should be a warning message if the file is not deleted from disk. I'm for warning that nothing was deleted. (2) fossil mv abc.txt xyz.txt will rename abc.txt to xyz.txt on disk provided that xyz.txt does not previously exist on disk or if xyz.txt does already exist and its content is identical to abc.txt. If xyz.txt does previously exist and is different from abc.txt (and hence would be overwritten) then the operation just fails out-right with an appropriate error message. Great. Sincerely, Gour -- From anger, complete delusion arises, and from delusion bewilderment of memory. When memory is bewildered, intelligence is lost, and when intelligence is lost one falls down again into the material pool. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
(1) fossil rm xyx.txt will remove the file xyz.txt from disk if and only if an exact copy of xyz.txt exists under control. If xyz.txt has been modified or if xyz.txt has never been checked in (and the fossil rm is simply to reverse a prior fossil add) then xyz.txt is unchanged. Either way, there are probably no error or warning messages, though I am sympathetic to the argument that there should be a warning message if the file is not deleted from disk. I think that there should be a warning message (2) fossil mv abc.txt xyz.txt will rename abc.txt to xyz.txt on disk provided that xyz.txt does not previously exist on disk or if xyz.txt does already exist and its content is identical to abc.txt. If xyz.txt does previously exist and is different from abc.txt (and hence would be overwritten) then the operation just fails out-right with an appropriate error message. You should define clearly what to do in case xyz.txt directory does not exist or is not writable. if it is not writable, just fail and error message if the directory does not exist: a) the simple one, give and error b) Try to create the directories too 2012/12/13 Richard Hipp d...@sqlite.org: FWIW, I am following this thread with great interest. I think I understand the various points of view. I think most everybody brings up good points, and I encourage this kind of discussion. My current leanings are to change rm and mv as follows: (1) fossil rm xyx.txt will remove the file xyz.txt from disk if and only if an exact copy of xyz.txt exists under control. If xyz.txt has been modified or if xyz.txt has never been checked in (and the fossil rm is simply to reverse a prior fossil add) then xyz.txt is unchanged. Either way, there are probably no error or warning messages, though I am sympathetic to the argument that there should be a warning message if the file is not deleted from disk. (2) fossil mv abc.txt xyz.txt will rename abc.txt to xyz.txt on disk provided that xyz.txt does not previously exist on disk or if xyz.txt does already exist and its content is identical to abc.txt. If xyz.txt does previously exist and is different from abc.txt (and hence would be overwritten) then the operation just fails out-right with an appropriate error message. It seems to me that the behaviors above are the most intuitive and provide developers with the least amount of surprise. The goal of Fossil (as it should be for any VCS) is to get out of the developer's way and just do the right thing, so that the developer can devote maximum brain-power to working on their application, and expend a minimum number of brain-cycles thinking about Fossil and how to control it. And I think the behaviors outlined above probably best achieve this goal. But I am far from certain of that, so please do continue debating the issue. We want to get this right. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
2012/12/13 Nolan Darilek no...@thewordnerd.info On 12/13/2012 08:40 AM, Marcelo wrote: They want the good things about fossil but they want to keep working as if it were Git. I say, if they like Git so much, eat the crow that comes with it. And that doesn't even make sense, either. If I wanted Git, then I'd use Git, full stop. It's silly telling me that changing this rm behavior is suddenly going to make Fossil so like Git that I'm all like Oh, great, now I've succeeded in my nefarious mission of making everything Git-like! Mine is an EVIL laugh! Next I'll ask for rebase! You may laugh at the image of the cackling, moustache twirling villain -- after all, I've used the image myself in hyperbole. But what you're deliberate neglecting is that rebase *has been requested already*, even when it goes against all what Fossil stands for. Not so silly any more, it seems. Making this sort of argument damages the cause because it puts those of us advocating for a thing in a position we aren't necessarily in, so it makes us want to just let the point go. I don't want Fossil to be another Git, but by telling me that I do, I'm suddenly either compelled to stop advocating for *any* change that violates Least Surprise. And hell, my example didn't even *use* Git's behavior to justify my claims and I'm *still* being told that OMG I want to make Fossil like teh gits! I respect the Fossil should be conservative arguments even though I disagree with them, but I'm going to call this exaggeration and hyperbole out on the carpet. Go ahead, call it whatever tickles your fancy. I'm not adverse to use exaggeration and hyperbole to make a point, and I accept I did. So what? I don't think is a bad think to counter somewhat the impulse of advocating the full Git command line experience in Fossil just for the same of the muscle memory of some repentant Git users. Is fair to notice that the rm/mv issue is the one I have *less* objections about. Is the full cloning of command line options of other systems what's grating at my teeth right now. That and the advocacy for a rebase-like feature as The Only Right Way To Work With Source Code. -- o-= Marcelo =-o ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/13/2012 11:02 AM, Marcelo wrote: You may laugh at the image of the cackling, moustache twirling villain -- after all, I've used the image myself in hyperbole. But what you're deliberate neglecting is that rebase *has been requested already*, even when it goes against all what Fossil stands for. Not so silly any more, it seems. But it's still happening. You don't get to reframe this discussion by putting everyone who asks for a change in the same category. Sorry, I won't let you do that. Me asking for rm behavior today does not mean I'll ask for rebase tomorrow, nor does it mean that someone who does has *anything to do* with requesting a certain rm behavior today. And just to be clear, I dislike rebase. Were I to jump ship to another VCS, it'd be Mercurial because it supports a very Fossil-like view of history. I used to like Git's everything but the kitchen sink approach until I came to Fossil, and now I don't. Let's use a bit of hyperbole of my own. Should companies/projects like Google, Apple, Microsoft, GNOME, KDE and Mozilla abandon their adoption of some sort of human interface guidelines? These companies and projects manage to produce vastly different experiences, despite the fact that Ctrl-C, Ctrl-V, Ctrl-X and Ctrl-Z do vastly similar things across them all. Saying that GNOME or KDE is suddenly going to be like OS X or Windows 8 because it uses the same key commands doesn't make sense, and I think it'd be exaggeration to accuse GNOME or Mozilla of heading down the path of Windows were it not to have these keyboard shortcuts and suddenly choose to adopt them. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, 13 Dec 2012 18:02:25 +0100, Marcelo richiead...@gmail.com wrote: 2012/12/13 Nolan Darilek no...@thewordnerd.info On 12/13/2012 08:40 AM, Marcelo wrote: They want the good things about fossil but they want to keep working as if it were Git. I say, if they like Git so much, eat the crow that comes with it. And that doesn't even make sense, either. If I wanted Git, then I'd use Git, full stop. It's silly telling me that changing this rm behavior is suddenly going to make Fossil so like Git that I'm all like Oh, great, now I've succeeded in my nefarious mission of making everything Git-like! Mine is an EVIL laugh! Next I'll ask for rebase! You may laugh at the image of the cackling, moustache twirling villain -- after all, I've used the image myself in hyperbole. But what you're deliberate neglecting is that rebase *has been requested already*, even when it goes against all what Fossil stands for. Not so silly any more, it seems. Making this sort of argument damages the cause because it puts those of us advocating for a thing in a position we aren't necessarily in, so it makes us want to just let the point go. I don't want Fossil to be another Git, but by telling me that I do, I'm suddenly either compelled to stop advocating for *any* change that violates Least Surprise. And hell, my example didn't even *use* Git's behavior to justify my claims and I'm *still* being told that OMG I want to make Fossil like teh gits! I respect the Fossil should be conservative arguments even though I disagree with them, but I'm going to call this exaggeration and hyperbole out on the carpet. Go ahead, call it whatever tickles your fancy. I'm not adverse to use exaggeration and hyperbole to make a point, and I accept I did. So what? it's annoying/exhausting. that's what. I don't think is a bad think to counter somewhat the impulse of advocating the full Git command line experience in Fossil just for the same of the muscle memory of some repentant Git users. really: why not stop this nonsense/aggressiveness? nobody needs this (yourself included I presume) Is fair to notice that the rm/mv issue is the one I have *less* objections about. Is the full cloning of command line options of other systems fine. that's what we are talking about. what's grating at my teeth right now. That and the advocacy for a rebase-like feature as The Only Right Way To Work With Source Code. I don't miss rebase right now (and yes: that feature exists out there in the wild (git, mercurial, probably others). personally, though, I find it rather easy to ignore unwanted features/commands. and I _know_ there are projects making good use of rebase without saying that other roads to not lead to Rome, too. you need not use it if you don't like it. it's not an evil feature per se. but again: I don't care for it, currently. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, Dec 13, 2012 at 6:13 PM, Nolan Darilek no...@thewordnerd.info wrote: You don't get to reframe this discussion by putting everyone who asks for a change in the same category. Sorry, I won't let you do that. Me asking for rm behavior today does not mean I'll ask for rebase tomorrow, nor does it mean that someone who does has *anything to do* with requesting a certain rm behavior today. Moreover, asking for changes and improvements shouldn't be taboo, even if these proposed changes are inspired by other (perhaps worse) tools. Ultimately, it is up to the maintainers to weed out the proposals, rejecting these who don't match the vision and perhaps adopting (and adapting) others that can be useful. This kind of discussion, while civilized, can only be good. J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit. IMO, as somebody else suggested in the thread, let fossil do rm or mv only in version control. In order to satisfy need of fossil users asking for changes in file system, I suggest an option -f be given, which acts as suggested in your mail. With this option if fossil decides not to rm or mv any file in file system, it should print reason for deciding so. - Original Message - From: Richard Hipp Sent: 12/13/12 09:08 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] why does `fossil rm' not do the real thing? FWIW, I am following this thread with great interest. I think I understand the various points of view. I think most everybody brings up good points, and I encourage this kind of discussion. My current leanings are to change rm and mv as follows: (1) fossil rm xyx.txt will remove the file xyz.txt from disk if and only if an exact copy of xyz.txt exists under control. If xyz.txt has been modified or if xyz.txt has never been checked in (and the fossil rm is simply to reverse a prior fossil add) then xyz.txt is unchanged. Either way, there are probably no error or warning messages, though I am sympathetic to the argument that there should be a warning message if the file is not deleted from disk. (2) fossil mv abc.txt xyz.txt will rename abc.txt to xyz.txt on disk provided that xyz.txt does not previously exist on disk or if xyz.txt does already exist and its content is identical to abc.txt. If xyz.txt does previously exist and is different from abc.txt (and hence would be overwritten) then the operation just fails out-right with an appropriate error message. It seems to me that the behaviors above are the most intuitive and provide developers with the least amount of surprise. The goal of Fossil (as it should be for any VCS) is to get out of the developer's way and just do the right thing, so that the developer can devote maximum brain-power to working on their application, and expend a minimum number of brain-cycles thinking about Fossil and how to control it. And I think the behaviors outlined above probably best achieve this goal. But I am far from certain of that, so please do continue debating the issue. We want to get this right. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/13/2012 07:38 AM, Richard Hipp wrote: FWIW, I am following this thread with great interest. I think I understand the various points of view. I think most everybody brings up good points, and I encourage this kind of discussion. My current leanings are to change rm and mv as follows: I like these proposed changes. I don't think I've ever done one rm/mv without the other (i.e. rm in fossil without also rm'ing on disk), so this'd save me some steps and typing 100% of the time. thanks, Richard! (1) fossil rm xyx.txt will remove the file xyz.txt from disk if and only if an exact copy of xyz.txt exists under control. If xyz.txt has been modified or if xyz.txt has never been checked in (and the fossil rm is simply to reverse a prior fossil add) then xyz.txt is unchanged. Either way, there are probably no error or warning messages, though I am sympathetic to the argument that there should be a warning message if the file is not deleted from disk. (2) fossil mv abc.txt xyz.txt will rename abc.txt to xyz.txt on disk provided that xyz.txt does not previously exist on disk or if xyz.txt does already exist and its content is identical to abc.txt. If xyz.txt does previously exist and is different from abc.txt (and hence would be overwritten) then the operation just fails out-right with an appropriate error message. It seems to me that the behaviors above are the most intuitive and provide developers with the least amount of surprise. The goal of Fossil (as it should be for any VCS) is to get out of the developer's way and just do the right thing, so that the developer can devote maximum brain-power to working on their application, and expend a minimum number of brain-cycles thinking about Fossil and how to control it. And I think the behaviors outlined above probably best achieve this goal. But I am far from certain of that, so please do continue debating the issue. We want to get this right. -- D. Richard Hipp d...@sqlite.org mailto:d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com wrote: In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit. Well, yes, that is the way I do it too. I suspect that there are some who do not review their changes before commit, and that many of those commit way too often, essentially treating their VCS as a backup method. This of course leads to junk, non-functional checkins, followed by an unhealthy interest in rebase-like functionality. On another note, people are saying things like there is a certain behaviour that is expected without saying why it is expected. The main reasons seem to be that other VCS's do it and that it saves time. The first is irrelevant and the second, in my opinion, a case of people knowing the price of everything and the value of nothing. I think this thread has served to highlight the number of people here who want Fossil to be something other that what it set out to be, and don't actually know what SCM means. It doesn't surprise me that they have caused some over-the-top reactions. Eric -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, Dec 13, 2012 at 6:08 PM, Eric e...@deptj.eu wrote: On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com wrote: In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit. Well, yes, that is the way I do it too. I suspect that there are some who do not review their changes before commit, and that many of those commit way too often, essentially treating their VCS as a backup method. This of course leads to junk, non-functional checkins, followed by an unhealthy interest in rebase-like functionality. Well put. So Altu and Eric (and also Joe Mistachkin on a back-channel) have pretty much convinced me at this point to keep the current behavior of fossil rm and fossil mv. But, should there be an opt-in option to also make the disk changes? Perhaps fossil rm abc.txt just removes abc.txt from configuration management, but fossil rm -f abc.txt also removes it from disk? And/or should there be a warning printed: File abc.txt removed from management but unchanged on disk just to give a heads-up to newcomers who expect different behavior? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, 14 Dec 2012 00:08:04 +0100, Eric e...@deptj.eu wrote: On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com wrote: In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit. Well, yes, that is the way I do it too. I suspect that there are some who do not review their changes before commit, and that many of those commit way too often, essentially treating their VCS as a backup method. This of course leads to junk, non-functional checkins, followed by an unhealthy interest in rebase-like functionality. On another note, people are saying things like there is a certain behaviour that is expected without saying why it is expected. The main reasons seem to be that other VCS's do it and that it saves time. The first is irrelevant and the second, in my opinion, a case of people knowing the price of everything and the value of nothing. I think this thread has served to highlight the number of people here who want Fossil to be something other that what it set out to be, and richard might decide that one, right? and even if it were true that this discussion revolves about the issue of morphing fossil into something else, which it is not, it could - theoretically - be a development in the right direction presuming that the initial design (goal) was not perfect in the strict sense of the word (which simply never can be the case in this world). but all this is 100% relevant to the point at hand. don't actually know what SCM means. It doesn't surprise me that they sure. dummies all of them. have caused some over-the-top reactions. altogether I see your mail as another (logical) non sequitur. j. Eric -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
* Richard Hipp d...@sqlite.org [20121213 16:37]: My current leanings are to change rm and mv as follows: [...] It seems to me that the behaviors above are the most intuitive and provide developers with the least amount of surprise. I agree. Regarding your later post, I fail to see how this proposed behaviour encourages VCS-as-backup sloppiness. qvb -- pica ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp d...@sqlite.org wrote: On Thu, Dec 13, 2012 at 6:08 PM, Eric e...@deptj.eu wrote: On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com wrote: In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit. Well, yes, that is the way I do it too. I suspect that there are some who do not review their changes before commit, and that many of those commit way too often, essentially treating their VCS as a backup method. This of course leads to junk, non-functional checkins, followed by an unhealthy interest in rebase-like functionality. Well put. I don't think so, actually. I've seen misuses (sort of) and misconceptions of SCMs here (on this list) and elsewhere. that happens. considering serious and sane use of SCM, I'm still perfectly sure that for the sole reason (repeated already way to often) that the by far most frequent use case of `fossil rm' and `fossil mv' will be a situation where the file system should reflect the change, the default behaviour should change. your previous suggestion in this direction did make perfect sense to me. the present one not so much. so I strongly opt for a default that does the real thing (yes!) of keeping repo and file system in sync (that's in my view what the SCM should always strive for. and to relegate different behaviour to the options, not the other way round. but, indeed, it is an interesting question why for heavens sake this issue does cause such a storm on this list? I don't get it. maybe it's too obvious to me that a default which forces me (and an estimate 99% of the other users) to type more than necessary -- which I don't like -- (and at the same time of running the risk of forgetting the additional actions and starting to mess things up) is no good while others have adjusted their mind to the current behaviour and don't want to change anything since it currently just works (tm). I can tell you from own experience that it definitely does not help to convince svn users, e.g., that fossil is a interesting system (which it is). and yes: this alone sure is no argument. but it _is_ an argument if essentially all of the competitors (that I know of) go for the `scm rm/mv' act on the filesystem as well strategy for a reason. anywayt, I think everything has been said now more than once. I'll try to keep radio silence regarding this topic from know own (see whether I'm successful...). looking forward to the upcoming releases. I'll manage to use fossil in any case. j. So Altu and Eric (and also Joe Mistachkin on a back-channel) have pretty much convinced me at this point to keep the current behavior of fossil rm and fossil mv. But, should there be an opt-in option to also make the disk changes? Perhaps fossil rm abc.txt just removes abc.txt from configuration management, but fossil rm -f abc.txt also removes it from disk? And/or should there be a warning printed: File abc.txt removed from management but unchanged on disk just to give a heads-up to newcomers who expect different behavior? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Who would have guessed that something as simple as having rm remove the file from disk would prompt opponents to: * claim that I want Fossil to be like Git. * Call me lazy. * Insult my intelligence by claiming that I don't know what a VCS is or should do. Done with this thread. Keep it classy, detractors. On 12/13/2012 05:08 PM, Eric wrote: On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com wrote: In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit. Well, yes, that is the way I do it too. I suspect that there are some who do not review their changes before commit, and that many of those commit way too often, essentially treating their VCS as a backup method. This of course leads to junk, non-functional checkins, followed by an unhealthy interest in rebase-like functionality. On another note, people are saying things like there is a certain behaviour that is expected without saying why it is expected. The main reasons seem to be that other VCS's do it and that it saves time. The first is irrelevant and the second, in my opinion, a case of people knowing the price of everything and the value of nothing. I think this thread has served to highlight the number of people here who want Fossil to be something other that what it set out to be, and don't actually know what SCM means. It doesn't surprise me that they have caused some over-the-top reactions. Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, Dec 13, 2012 at 4:48 PM, j. v. d. hoff veedeeh...@googlemail.comwrote: On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp d...@sqlite.org wrote: On Thu, Dec 13, 2012 at 6:08 PM, Eric e...@deptj.eu wrote: On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com wrote: In order to continue the debate: In my work flow, I do rm or mv in file system as and when needed. I do fossil rm or fossil mv only when reviewing my changes before commit. Well, yes, that is the way I do it too. I suspect that there are some who do not review their changes before commit, and that many of those commit way too often, essentially treating their VCS as a backup method. This of course leads to junk, non-functional checkins, followed by an unhealthy interest in rebase-like functionality. Well put. I don't think so, actually. I've seen misuses (sort of) and misconceptions of SCMs here (on this list) and elsewhere. that happens. considering serious and sane use of SCM, I'm still perfectly sure that for the sole reason (repeated already way to often) that the by far most frequent use case of `fossil rm' and `fossil mv' will be a situation where the file system should reflect the change, the default behaviour should change. your previous suggestion in this direction did make perfect sense to me. the present one not so much. so I strongly opt for a default that does the real thing (yes!) of keeping repo and file system in sync (that's in my view what the SCM should always strive for. and to relegate different behaviour to the options, not the other way round. but, indeed, it is an interesting question why for heavens sake this issue does cause such a storm on this list? I don't get it. maybe it's too obvious to me that a default which forces me (and an estimate 99% of the other users) to type more than necessary -- which I don't like -- (and at the same time of running the risk of forgetting the additional actions and starting to mess things up) is no good while others have adjusted their mind to the current behaviour and don't want to change anything since it currently just works (tm). This is the classical divide between pragmatists (I want to get my job with with minimal pain so I can go home a play ball with my son) versus the idealists (source code management means doing x, y and z and no more and no less and I'm sorry that it will take you twice as long to do your job right *grin*). Fossil is caught between the messy world of the pragmatists and the nice tidy world of the idealists. There is no one right way to do it. One group or the other will be disappointed. When I saw that fossil was leaning more towards the idealistic side I created my fsl wrapper to make fossil workable in a real-world arena. Without my wrapper fossil would be unusable in our team. Maybe it is time for a more robust, written in C or similar, wrapper that adapts fossil for the pragmatists allowing the idealists to have their pristine usage model. Is this something that could be formally architected to be part of the fossil project? Basically it would be one tool with two faces. It is just a thought. My wrapper needs some work (I never did finish off the -r and -f for rm) but it works well enough for now. You can get it at https://chiselapp.com/user/kiatoa/repository/fsl/index and I very much welcome suggestions for improvement. Keep in mind that it is intended to make life easy for those on large teams working with large numbers of fossils (we have over two hundred fossils in use right now) in a pure Unix environment. I can tell you from own experience that it definitely does not help to convince svn users, e.g., that fossil is a interesting system (which it is). and yes: this alone sure is no argument. but it _is_ an argument if essentially all of the competitors (that I know of) go for the `scm rm/mv' act on the filesystem as well strategy for a reason. anywayt, I think everything has been said now more than once. I'll try to keep radio silence regarding this topic from know own (see whether I'm successful...). looking forward to the upcoming releases. I'll manage to use fossil in any case. j. So Altu and Eric (and also Joe Mistachkin on a back-channel) have pretty much convinced me at this point to keep the current behavior of fossil rm and fossil mv. But, should there be an opt-in option to also make the disk changes? Perhaps fossil rm abc.txt just removes abc.txt from configuration management, but fossil rm -f abc.txt also removes it from disk? And/or should there be a warning printed: File abc.txt removed from management but unchanged on disk just to give a heads-up to newcomers who expect different behavior? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org
Re: [fossil-users] why does `fossil rm' not do the real thing?
Well, yes, that is the way I do it too. I suspect that there are some who do not review their changes before commit, and that many of those commit way too often, essentially treating their VCS as a backup method. This of course leads to junk, non-functional checkins, followed by an unhealthy interest in rebase-like functionality. Well put. With all sincerity I fail to see why this is well put. That paragraph is basically criticizing the rest of the people that is not using an VCS in the same way that the poster likes to use. Why is it not correct to commit often? Why is it an advantage to always make a deep review of what is going to be commited? Why the timeline needs to be pretty and delicately handmade? In my opinion a VCS can be used in many different ways depending on the type of application, size of the dev team, company policies, etc. Trying to enforce one of these ways of working is just plain reductionism. At the end we are discussing something very simple: Which default usage is more convenient for most users? Once one default is selected, are we causing a great pain to the non favoured users? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Wed, Dec 12, 2012 at 1:24 AM, Jan Danielsson jan.m.daniels...@gmail.comwrote: I'm willing to bet that the number of times people will type fossil mv/rm X Y and not actually want to mv/rm X to Y just afterwards is vanishingly small. More to the point; let's reverse your -s-flag; I.e.: $ fossil mv X Y ... renames X to Y (metadata and filesystem). $ fossil -d mv X Y ... as in Don't actually move will only change the metadata, and the user can then use the mv command afterwards to manually rename/move the file in the filesystem. The last option doesn't make any sense at all. Which is sort of my point.. I think such an option would be used roughly zero times; but your proposed -s would be used almost 100% of the time (when people learn about it). And this goes back to that ten things I hate about git-list; when commands counter-intuitively require extra flags to get the canonical behavior. While the numbers may be in favor of the -s or whatever option, I doubt the other behavior would be used zero times. It happens occasionally that I want to remove a file from version control, but not the actual file. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
As I understand it, fossil currently deletes one file from disk when doing and update if this file has been removed by another user. For me, it is incoherent that fossil does not do the same on commit. Of course, only for the case that there is a copy of the file in the previous version and that there are no changes in it. In the latter case, no information can be lost, and the file is already contained in the previous version and can be checkout from there if necessary. RR 2012/12/12 Baruch Burstein bmburst...@gmail.com While the numbers may be in favor of the -s or whatever option, I doubt the other behavior would be used zero times. It happens occasionally that I want to remove a file from version control, but not the actual file ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Le 2012-12-12 06:28, Ramon Ribó a écrit : As I understand it, fossil currently deletes one file from disk when doing and update if this file has been removed by another user. For me, it is incoherent that fossil does not do the same on commit. Of course, only for the case that there is a copy of the file in the previous version and that there are no changes in it. In the latter case, no information can be lost, and the file is already contained in the previous version and can be checkout from there if necessary. It's in that case where a -f would be useful. I would expect: fossil rm file, to remove the file on checkout if the file is in sync with the repository, but command to fail if the file is locally modified. In the case where the user really want to delete change that never get committed, he can use: fossil rm -f file That way, there's no danger of accidental data lost. If you call fossil rm by mistake, file can be retrieve from previous version on the repository. snip ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Chad Perrin decía, en el mensaje Re: [fossil-users] why does `fossil rm' not do the real thing? del Miércoles, 12 de Diciembre de 2012 18:22:53: I rather suspect that, if Fossil continues to grow in usage over time, and if it fails to implement sane defaults and options like what you just described as a general policy, there will probably be either a fork or a wrapper that arrives to solve the problem. If that happens, please make sure to include git in the new name. That's what all the naysayers are trying to convert Fossil into, anyway. -- o-= Marcelo =-o ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler richiead...@gmail.com wrote: If that happens, please make sure to include git in the new name. That's what all the naysayers are trying to convert Fossil into, anyway. +1 :) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Wed, Dec 12, 2012 at 03:07:51PM -0800, Themba Fletcher wrote: On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler richiead...@gmail.com wrote: If that happens, please make sure to include git in the new name. That's what all the naysayers are trying to convert Fossil into, anyway. +1 :) Screw that. Git makes exactly the kind of UI mistakes I'm talking about eliminating. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Thu, Dec 13, 2012 at 12:13 AM, Chad Perrin c...@apotheon.net wrote: Screw that. Git makes exactly the kind of UI mistakes I'm talking about eliminating. Well, one thing that I don't know whether to call UI mistake, but it is certainly an inconvenience, is that to obtain accurate status information (similar to git status, bzr status, etc.) you must do fossil status ; or fossil changes fossil extras --dotfiles J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Wed, Dec 12, 2012 at 3:13 PM, Chad Perrin c...@apotheon.net wrote: On Wed, Dec 12, 2012 at 03:07:51PM -0800, Themba Fletcher wrote: On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler richiead...@gmail.com wrote: If that happens, please make sure to include git in the new name. That's what all the naysayers are trying to convert Fossil into, anyway. +1 :) Screw that. Git makes exactly the kind of UI mistakes I'm talking about eliminating. Sorry for the hasty and flippant reply -- poor judgement on my part given the passion involved in this discussion. It seems to all boil down to what's a sane default and how liberal fossil should be about removing a file from the disk. I obviously prefer the current, conservative, behavior, and it's one of fossil's selling points as far as I'm concerned. This discussion has devolved somewhat into a comparison with other systems and speculation about user growth if fossil fails to conform, which I think may be getting somewhat counterproductive. I'd like to return to what I think should be the focus, which is discussing what the right thing is for fossil to do. As a possible compromise, the combination of a '-f' flag to fossil rm with the ability to add aliases (mentioned as a possible feature by Richard recently in another thread if I'm not mistaken) could solve this completely. The default could remain as is, safe and conservative, and the only downside would be the necessity of communicating the option to new users to alias 'fossil rm' to 'fossil rm -f'. I'll of course even volunteer to write the FAQ entry if this becomes a reality (since I don't really have any place mucking about with fossil's internals). Again, my apologies for adding noise earlier to an important discussion. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
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. On 12/12/2012 05:38 PM, Juanma Barranquero wrote: On Thu, Dec 13, 2012 at 12:13 AM, Chad Perrin c...@apotheon.net wrote: Screw that. Git makes exactly the kind of UI mistakes I'm talking about eliminating. Well, one thing that I don't know whether to call UI mistake, but it is certainly an inconvenience, is that to obtain accurate status information (similar to git status, bzr status, etc.) you must do fossil status ; or fossil changes fossil extras --dotfiles J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/12/2012 08:42 PM, Richie Adler wrote: What's next? Replacing SQLite with individual files? Absolutely not, and statements like this do more harm than good because they willfully disregard the point of what is being expressed. The point is not to be alarmist and extreme, as statements like the above are. The point is to establish that there is a certain behavior that is expected, and Fossil does not exemplify that. Saying next you'll want to change the file format is silly, because expectations about a thing like file format are *nowhere near the same category* as something like what rm should do. In day to day operation, I care nothing about the file format. I care a whole lot more about whether or not I have to perform several operations to remove a file, when Fossil as a tool could make that work easier for me and not sacrifice data as several posters have already noted. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Wed, 12 Dec 2012 23:42:29 -0300 Richie Adler richiead...@gmail.com wrote: Sorry, I still think that the intention is to destroy what Fossil has of unique to offer to be able to say that Git or Mercurial it's the same and they should be preferred to Fossil. What's next? Replacing SQLite with individual files? Can you please change your mantra labelling every constructive attempt to change something in Fossil as conspiracy by Git advocates. Thank you. Sincerely, Gour -- As a strong wind sweeps away a boat on the water, even one of the roaming senses on which the mind focuses can carry away a man's intelligence. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Nolan Darilek no...@thewordnerd.info 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? 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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
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
Re: [fossil-users] why does `fossil rm' not do the real thing?
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 themba.fletc...@gmail.com 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 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Tue, Dec 11, 2012 at 3:08 PM, K k...@lightpowered.org 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 themba.fletc...@gmail.com 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 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Tue, 11 Dec 2012 22:50:06 +0100, Themba Fletcher themba.fletc...@gmail.com 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 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. for me it's about what is the most sane (or probably expected) default behavior for the majority of users. this question has been answered several times by the developers/users of other SCMs (hg, svn, ...) to the extent that `rm' and 'mv' should act on the files in the checkout as well. for me, they were right: when executing commands via the SCM (fossil in the present context) one can _expect_ that something will happen to the checkout and that fossil's opinion of what the state of the project is should be in sync with the checkout as far as possible. _usually_ `fossil mv' and `fossil rm' should imply that the action is applied to the checkout as well (do the rename or deletion of the file). more often than not (I'd say) that's what the user will want to happen. and that's what the default behavior should cover. of course I understand that this might exactly be _not_ your use case. but we are talking about _default_ behavior (and possibly delegating diverging behavior to options). in my use case I _always_ have to mv/rm (mv is especially bad, if forgotten) the checkout files manually and my suspicion is that's exactly what the majority of users will do currently. which would indicate that the current behavior is suboptimal. best regards, joerg 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 -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On 12/11/12 23:08, K 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. Say during your lifetime you'll (re)move 1000 files in fossil repositories. That means you'll in practice perform 2000 (re)move operations (once in metadata, and once in the filesystem). At what point would one expect to have been sufficiently reminded and taught how to (re)move files? Personally, I have never learned anything of value from having to (re)move files twice. And I don't really buy the It's safer argument either. I have several times become confused over what operations I have actually performed because the file-system isn't in sync with the operations I have performed; and becoming confused over what operations one has performed because the filesystem doesn't reflect it is not safe. I'm willing to bet that the number of times people will type fossil mv/rm X Y and not actually want to mv/rm X to Y just afterwards is vanishingly small. More to the point; let's reverse your -s-flag; I.e.: $ fossil mv X Y ... renames X to Y (metadata and filesystem). $ fossil -d mv X Y ... as in Don't actually move will only change the metadata, and the user can then use the mv command afterwards to manually rename/move the file in the filesystem. The last option doesn't make any sense at all. Which is sort of my point.. I think such an option would be used roughly zero times; but your proposed -s would be used almost 100% of the time (when people learn about it). And this goes back to that ten things I hate about git-list; when commands counter-intuitively require extra flags to get the canonical behavior. (I did some serious refactoring recently which involved lots of mv and a few rm, and it really annoyed me that my computer, which is supposedly a machine for automating tasks, required me to perform an extra manual step for each mv and rm). (Yes, I ended up scripting it in the end .. but that just further annoyed me; why do I need to script operations in fossil to get the canonical behavior?). I too am a little skeptical about adding too many settings to fossil, but this is definitely one that I would think merits a setting if the current (default) behavior is kept in 2.0. Sorry if this came out as a rant; it's not directed at anyone personally, but like I said, I battled fossil rm/mv recently and I'm still not completely over it. No flame-bait intended. -- Kind regards, Jan Danielsson ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote: On Tue, 20 Nov 2012 16:48:00 +0100, James Turner I'd suggest -f like cvs rm uses. obviously everybody seems to have his/her own preference how to handle this. so only a fraction of users will be happy in the end it seems. -- I would again second the proposal of Remigiusz Modrzejewski in this thread: after a 'grace' period when it would behave in the way you propose (explicitly add a -f flag to enforce deletion), finally change the default to what _current_ VCSs (= svn) seemingly all (?) do by default which is to treat `svn(hg, git, bzr) rm' as meaning remove from repository and also remove the working copy while relegating different behaviour (if at all) to an option such as bzr rm --keep. in my way that is the most frequently intended behaviour which should therefore be the default. sure a matter of taste as so many things, but at least it would avoid surprises here for refugees from one of the other systems. I think that makes sense, with the addition of using Matt Welland's suggestion of scheduling the move to compatibility breaking behavior on a 2.0 release. This is the purpose of common semantic versioning, after all: major version numbers (the integer portion, essentially) are for indicating breakage in backward compatibility for system features. I think that doggedly sticking to current default behavior for all time is a bad idea for a number of reasons[1], but that making changes to expected defaults before a major version number increment is also a rather bad idea. [1]: . . . such as potential for error when using multiple DVCSes in parallel and discouraging people from adopting the software. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Fri, 30 Nov 2012 15:30:13 +0100, Chad Perrin c...@apotheon.net wrote: On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote: On Tue, 20 Nov 2012 16:48:00 +0100, James Turner I'd suggest -f like cvs rm uses. obviously everybody seems to have his/her own preference how to handle this. so only a fraction of users will be happy in the end it seems. -- I would again second the proposal of Remigiusz Modrzejewski in this thread: after a 'grace' period when it would behave in the way you propose (explicitly add a -f flag to enforce deletion), finally change the default to what _current_ VCSs (= svn) seemingly all (?) do by default which is to treat `svn(hg, git, bzr) rm' as meaning remove from repository and also remove the working copy while relegating different behaviour (if at all) to an option such as bzr rm --keep. in my way that is the most frequently intended behaviour which should therefore be the default. sure a matter of taste as so many things, but at least it would avoid surprises here for refugees from one of the other systems. I think that makes sense, with the addition of using Matt Welland's suggestion of scheduling the move to compatibility breaking behavior on a 2.0 release. This is the purpose of common semantic versioning, after all: major version numbers (the integer portion, essentially) are for indicating breakage in backward compatibility for system features. I think that doggedly sticking to current default behavior for all time is a bad idea for a number of reasons[1], but that making changes to expected defaults before a major version number increment is also a rather bad idea. [1]: . . . such as potential for error when using multiple DVCSes in parallel and discouraging people from adopting the software. I fully support this reasoning. the last point, especially, is not to be taken lightly. but of course behind that is the basically more important aspect that it (i.e. `rm' doing both, removal from tracking and deleting the checked out copy) would be a saner default, probably. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
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? And is it not something that fossil revert could undo? 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. 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. On 11/30/2012 08:58 AM, j. v. d. hoff wrote: On Fri, 30 Nov 2012 15:30:13 +0100, Chad Perrin c...@apotheon.net wrote: On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote: On Tue, 20 Nov 2012 16:48:00 +0100, James Turner I'd suggest -f like cvs rm uses. obviously everybody seems to have his/her own preference how to handle this. so only a fraction of users will be happy in the end it seems. -- I would again second the proposal of Remigiusz Modrzejewski in this thread: after a 'grace' period when it would behave in the way you propose (explicitly add a -f flag to enforce deletion), finally change the default to what _current_ VCSs (= svn) seemingly all (?) do by default which is to treat `svn(hg, git, bzr) rm' as meaning remove from repository and also remove the working copy while relegating different behaviour (if at all) to an option such as bzr rm --keep. in my way that is the most frequently intended behaviour which should therefore be the default. sure a matter of taste as so many things, but at least it would avoid surprises here for refugees from one of the other systems. I think that makes sense, with the addition of using Matt Welland's suggestion of scheduling the move to compatibility breaking behavior on a 2.0 release. This is the purpose of common semantic versioning, after all: major version numbers (the integer portion, essentially) are for indicating breakage in backward compatibility for system features. I think that doggedly sticking to current default behavior for all time is a bad idea for a number of reasons[1], but that making changes to expected defaults before a major version number increment is also a rather bad idea. [1]: . . . such as potential for error when using multiple DVCSes in parallel and discouraging people from adopting the software. I fully support this reasoning. the last point, especially, is not to be taken lightly. but of course behind that is the basically more important aspect that it (i.e. `rm' doing both, removal from tracking and deleting the checked out copy) would be a saner default, probably. j. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] why does `fossil rm' not do the real thing?
I already stumbled a couple of times over the fact that `fossil rm' and `fossil mv' only act on the repository but not on the check out, i.e. I always have to issue two commands in order to actually remove a file from the (future of) the project. obviously this is different from other VCSs but I'm missing the point why it is a good idea to decouple both actions (removal from tracking and actual removal). any enlightenment appreciated... right now I'd say it'd be better to keep the actions coupled. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Tue, Nov 20, 2012 at 8:32 AM, j. van den hoff veedeeh...@googlemail.comwrote: I already stumbled a couple of times over the fact that `fossil rm' and `fossil mv' only act on the repository but not on the check out, i.e. I always have to issue two commands in order to actually remove a file from the (future of) the project. obviously this is different from other VCSs but I'm missing the point why it is a good idea to decouple both actions (removal from tracking and actual removal). any enlightenment appreciated... right now I'd say it'd be better to keep the actions coupled. CVS did not couple the actions, and I copied CVS in this regard. I agree with you now, that coupling them is the right thing to do. But I fear to change it because that might cause problems for existing scripts. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Tue, 20 Nov 2012 15:00:29 +0100, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Nov 20, 2012, at 14:45 , Richard Hipp wrote: CVS did not couple the actions, and I copied CVS in this regard. I agree with you now, that coupling them is the right thing to do. But I fear to change it because that might cause problems for existing scripts. This calls for making it a setting with a grace period of few releases before changing the default behavior... I'd second that. moreover, it's hard for me to see how real harm could be done. presuming that the last revision (or even the current) are part of the project history anyway an unintentional (as far as the respective old script is concerned) removal of the checked out file should not really be a problem, right? j. Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Tue, Nov 20, 2012 at 6:45 AM, Richard Hipp d...@sqlite.org wrote: On Tue, Nov 20, 2012 at 8:32 AM, j. van den hoff veedeeh...@googlemail.com wrote: I already stumbled a couple of times over the fact that `fossil rm' and `fossil mv' only act on the repository but not on the check out, i.e. I always have to issue two commands in order to actually remove a file from the (future of) the project. obviously this is different from other VCSs but I'm missing the point why it is a good idea to decouple both actions (removal from tracking and actual removal). any enlightenment appreciated... right now I'd say it'd be better to keep the actions coupled. CVS did not couple the actions, and I copied CVS in this regard. I agree with you now, that coupling them is the right thing to do. But I fear to change it because that might cause problems for existing scripts. How about starting a 2.0 development track that does not guarantee backwards compatibility in all regards? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/** fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
Richard Hipp wrote: [...] CVS did not couple the actions, and I copied CVS in this regard. I agree with you now, that coupling them is the right thing to do. But I fear to change it because that might cause problems for existing scripts. Add a -p for physical option to actually change the files, and leave the default as is? I agree, changing the existing behaviour would be a recipe for disaster. This, plus the ability to operate on directories (as in 'fossil commit subdir' or 'fossil mv subdir newname') are the two big items on my fossil wishlist. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true. --- Master Li Kao, │ _The Bridge of Birds_ signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Tue, Nov 20, 2012 at 03:39:06PM +, David Given wrote: Richard Hipp wrote: [...] CVS did not couple the actions, and I copied CVS in this regard. I agree with you now, that coupling them is the right thing to do. But I fear to change it because that might cause problems for existing scripts. Add a -p for physical option to actually change the files, and leave the default as is? I agree, changing the existing behaviour would be a recipe for disaster. I'd suggest -f like cvs rm uses. -- James Turner ja...@calminferno.net ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] why does `fossil rm' not do the real thing?
On Tue, 20 Nov 2012 16:48:00 +0100, James Turner ja...@calminferno.net wrote: On Tue, Nov 20, 2012 at 03:39:06PM +, David Given wrote: Richard Hipp wrote: [...] CVS did not couple the actions, and I copied CVS in this regard. I agree with you now, that coupling them is the right thing to do. But I fear to change it because that might cause problems for existing scripts. Add a -p for physical option to actually change the files, and leave the default as is? I agree, changing the existing behaviour would be a recipe for disaster. I'd suggest -f like cvs rm uses. obviously everybody seems to have his/her own preference how to handle this. so only a fraction of users will be happy in the end it seems. -- I would again second the proposal of Remigiusz Modrzejewski in this thread: after a 'grace' period when it would behave in the way you propose (explicitly add a -f flag to enforce deletion), finally change the default to what _current_ VCSs (= svn) seemingly all (?) do by default which is to treat `svn(hg, git, bzr) rm' as meaning remove from repository and also remove the working copy while relegating different behaviour (if at all) to an option such as bzr rm --keep. in my way that is the most frequently intended behaviour which should therefore be the default. sure a matter of taste as so many things, but at least it would avoid surprises here for refugees from one of the other systems. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
