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
[fossil-users] Possible future fossil rm behaviour
Hi there, there is another thread happening which is suggesting or proposing a future version of fossil rm which is not identical to the current one. What is the specific desired future behaviour? I think there are three possible future commands to be considered -- whether implemented as commands or as arguments is not of concern here. repo-only-rm -- mark as not part of the project repo-and-file-rm -- repo-only-rm, plus remove from the filesystem if safe repo-and-file-really-rm -- repo-only-rm, plus remove from the filesystem if possible Have I missed, or mischaracterised, any? (file-only-rm presumably remains outside of the fossil tool.) Currently, repo-only-rm is spelled rm; and the other two do not exist within fossil, so to achieve them one must use external scripting which reimplements at least part of the fossil logic to determine which files is a subdirectory should be considered. Avoiding the need to reimplement that logic is probably a good thing. Consider a straightforward case; files only (no directories) and nothing in ignore-glob: echo X a; echo X b; echo X c; fossil add a b fossil commit -m a and b = X echo Y b; echo Y c; fossil new-rm a fossil new-rm b fossil new-rm c fossil commit -m all gone What is the intended behaviour of each of the new-rm commands here? Which, if any, of the new-rm commands fail? If commands fail, what advice is given on how to make them succeed? What files exist in the filesystem after them? If files are gone, is there some way I can recover the Y for b and c? Thanks, f -- Francis Dalyfran...@daoine.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] Possible future fossil rm behaviour
On Fri, Dec 14, 2012 at 07:58:03PM +, Francis Daly wrote: Hi there, I forgot at least one case, which I can shoe-horn in here by adding: what would be different if rm a were added just before fossil new-rm a, as in: echo X a; echo X b; echo X c; fossil add a b fossil commit -m a and b = X echo Y b; echo Y c; rm a fossil new-rm a fossil new-rm b fossil new-rm c fossil commit -m all gone Thanks, f -- Francis Dalyfran...@daoine.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] Syncing with Github
Hi, I'd like to move some projects from Github to self-hosted fossil (or maybe chisel, I haven't decided yet). However, I'd like to keep the Github repository available and updated. I can do a one-time move with fast-export/fast-import, but that doesn't help for new code. I'm willing to have the Github repository only be computer writable, and have the Fossil repository be the Single Source of Truth. People may contribute code through pull requests, but once vetted I'll commit it to the Fossil repository myself. Has someone built something already (presumably using fast-import and fast-export, since those seem to be the go-to tool for cross-scm compatibility) to keep a git repository synced with a fossil one? cheers lvh ___ 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
[fossil-users] Obvious solution to the rm/mv problem?
Hello, It seems that some of those who are opposed to changing the behavior of rm/mv are reaching a consensus that the names rm and mv were poorly chosen, because they have a Unix connotation, and rename and move has been suggested instead. So -- is there any reason we can't have both? mv/rm - change to principle of least surprise move/remove - behaves like current mv/rm That way we all get what we want .. no? -- 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 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] Obvious solution to the rm/mv problem?
On Fri, Dec 14, 2012 at 7:20 PM, Jan Danielsson jan.m.daniels...@gmail.comwrote: Hello, It seems that some of those who are opposed to changing the behavior of rm/mv are reaching a consensus that the names rm and mv were poorly chosen, because they have a Unix connotation, and rename and move has been suggested instead. So -- is there any reason we can't have both? mv/rm - change to principle of least surprise move/remove - behaves like current mv/rm That way we all get what we want .. no? We have had (for a long time) commands delete and rename. rm is just an alias for delete and mv is an alias for rename. It would not be that hard to change just rm to remove files from disk (if it is safe to do so) but leave delete as the current behavior. Seems like a reasonable suggestion. -- 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 -- 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] Obvious solution to the rm/mv problem?
On Fri, Dec 14, 2012 at 5:29 PM, Richard Hipp d...@sqlite.org wrote: On Fri, Dec 14, 2012 at 7:20 PM, Jan Danielsson jan.m.daniels...@gmail.com wrote: Hello, It seems that some of those who are opposed to changing the behavior of rm/mv are reaching a consensus that the names rm and mv were poorly chosen, because they have a Unix connotation, and rename and move has been suggested instead. So -- is there any reason we can't have both? mv/rm - change to principle of least surprise move/remove - behaves like current mv/rm That way we all get what we want .. no? We have had (for a long time) commands delete and rename. rm is just an alias for delete and mv is an alias for rename. It would not be that hard to change just rm to remove files from disk (if it is safe to do so) but leave delete as the current behavior. Seems like a reasonable suggestion. Could I humbly suggest unmanage for the name of the remove-from-repo-and-leave-the-disk-alone command? This would be consistent with the status messages emitted by fossil (I think on merge?) and it's pretty clear from its name what it would do. This could leave us with the following commands: 1. unmanage -- remove from repo 2. delete -- unmanage and attempt to bring the disk to that state 3. rename -- change the name / path of a file in the repo 4. move -- rename as above, and bring the disk up to date I think this could be a pretty nice middle of the road compromise. As for what rm and mv are aliased to at that point -- I for one don't care. It's the continued existence of known safe (repo only) commands that keeps me smiling. Thanks, Themba -- 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 -- 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] Obvious solution to the rm/mv problem?
On Fri, Dec 14, 2012 at 8:58 PM, Themba Fletcher themba.fletc...@gmail.comwrote: Could I humbly suggest unmanage for the name of the remove-from-repo-and-leave-the-disk-alone command? This would be consistent with the status messages emitted by fossil (I think on merge?) and it's pretty clear from its name what it would do. I thought of that. In fact, I typed it into my previous posting to this list, but then deleted that paragraph before I pressed send. I could support unmanage as an alias for delete. It is suggested to me (off-list) that it would be too disruptive to abruptly change the meaning of fossil rm to start deleting from disk. So I propose a staged implementation: 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 This could leave us with the following commands: 1. unmanage -- remove from repo 2. delete -- unmanage and attempt to bring the disk to that state 3. rename -- change the name / path of a file in the repo 4. move -- rename as above, and bring the disk up to date I think this could be a pretty nice middle of the road compromise. As for what rm and mv are aliased to at that point -- I for one don't care. It's the continued existence of known safe (repo only) commands that keeps me smiling. -- 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] Improvements to side-by-side diff
Reposted from fossil-dev: OLD: http://www2.sqlite.org/src/ci/52e755943f?sbs=1#chunk1 NEW: http://www.sqlite.org/src/ci/52e755943f?sbs=1#chunk1 OLD: http://www2.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24 NEW: http://www.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24 Comments, suggestions, and (constructive) criticism are all welcomed. Also welcomed are examples of diffs that do not perform well using the new diff logic. Note that I will eventually update the Fossil executables on the OLD machines above, so if you are viewing this more than a week or so after it was posted (2012-12-14) then the OLD and NEW will likely look the same. -- 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] Obvious solution to the rm/mv problem?
On 12/15/12 03:15, Richard Hipp wrote: [---] It is suggested to me (off-list) that it would be too disruptive to abruptly change the meaning of fossil rm to start deleting from disk. So I propose a staged implementation: 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 vote Yes to all the above. -- 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] Obvious solution to the rm/mv problem?
On 12/14/2012 06:15 PM, Richard Hipp wrote: On Fri, Dec 14, 2012 at 8:58 PM, Themba Fletcher themba.fletc...@gmail.com mailto:themba.fletc...@gmail.com wrote: Could I humbly suggest unmanage for the name of the remove-from-repo-and-leave-the-disk-alone command? This would be consistent with the status messages emitted by fossil (I think on merge?) and it's pretty clear from its name what it would do. I thought of that. In fact, I typed it into my previous posting to this list, but then deleted that paragraph before I pressed send. I could support unmanage as an alias for delete. It is suggested to me (off-list) that it would be too disruptive to abruptly change the meaning of fossil rm to start deleting from disk. So I propose a staged implementation: 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 I like this a lot, especially (b) as a reminder to delete the file, in the even that I'd forget the -f. Will the 'mv' behavior be changed to work the same way? Stage 2 (after a stage 1 has been released for a while): (e) fossil rm works just like fossil rm -f Yep, +1 to this too. thanks! Steve This could leave us with the following commands: 1. unmanage -- remove from repo 2. delete -- unmanage and attempt to bring the disk to that state 3. rename -- change the name / path of a file in the repo 4. move -- rename as above, and bring the disk up to date I think this could be a pretty nice middle of the road compromise. As for what rm and mv are aliased to at that point -- I for one don't care. It's the continued existence of known safe (repo only) commands that keeps me smiling. -- 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 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] Obvious solution to the rm/mv problem?
On Sat, Dec 15, 2012 at 03:44:28AM +0100, Jan Danielsson wrote: On 12/15/12 03:15, Richard Hipp wrote: [---] It is suggested to me (off-list) that it would be too disruptive to abruptly change the meaning of fossil rm to start deleting from disk. So I propose a staged implementation: 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 vote Yes to all the above. +1 -- 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] Improvements to side-by-side diff
I've been meaning to post this for a while. On every browser except
firefox, at least with my installed fonts, the side-by-side diff container
overflows the body resulting in the body's border being visible as a
vertical gray line behind the diff content.
This will fix that, if you'd like to have it. Nothing special here, just
bog-standard css repeated in blogs all over the net:
Index: src/style.c
==
--- src/style.c
+++ src/style.c
@@ -961,10 +961,14 @@
{ div.sbsdiff,
side-by-side diff display,
@ font-family: monospace;
@ font-size: smaller;
@ white-space: pre;
+@ background: white;
+@ display: inline-block;
+@ zoom: 1;/* IE 6/7 substitute for inline-block */
+@ *display: inline; /* IE 6/7 substitute for inline-block */
},
{ div.udiff,
context diff display,
@ font-family: monospace;
@ white-space: pre;
The lines commented as IE6/7 workarounds are that, but for me at least they
seem to be required or else IE8 chokes on it. Probably has something to do
with the size of the inline-block element.
Tested with your links above on IE7-9 (IE9 in its compatibility modes, so
not the real thing but should be close enough), latest firefox, and latest
chrome.
Best Regards,
Themba
On Fri, Dec 14, 2012 at 6:16 PM, Richard Hipp d...@sqlite.org wrote:
Reposted from fossil-dev:
OLD: http://www2.sqlite.org/src/ci/52e755943f?sbs=1#chunk1
NEW: http://www.sqlite.org/src/ci/52e755943f?sbs=1#chunk1
OLD:
http://www2.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24
NEW:
http://www.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24
Comments, suggestions, and (constructive) criticism are all welcomed.
Also welcomed are examples of diffs that do not perform well using the new
diff logic.
Note that I will eventually update the Fossil executables on the OLD
machines above, so if you are viewing this more than a week or so after it
was posted (2012-12-14) then the OLD and NEW will likely look the same.
--
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
