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] applied DVCS for collaborative work - on the fossil project itself, or otherwise
One partial solution available today is to use http://chiselapp.com. Simply use their clone repo feature with regular pull. What is missing is a way to register the fork with the original project. It would be cool if it was possible to submit the URL of the forked repo to the parent. The parent can verify that the URL is a real fork and not some random URL and then make the forks (with description?) browseable on a Forks page. The final piece of the puzzle would be the mechanism to pull only a single branch from a remote repo. What are the technical challenges with that? Is it enough to query the db for all the nodes on the branch and pull only that data or is there more to it? On Wed, Dec 12, 2012 at 3:27 PM, C. Thomas Stover c...@thomasstover.comwrote: blabbing I have made some great progress on my continuing quest for fire with Fossil yesterday and today. In this episode, my juggling of over-committed time cycled back around to answering questions about branching and merging in the context of various development models using Fossil. In no way am I ashamed to say this this entire area (not just with Fossil) can be exceedingly complex, and really can make an old dog feel incapable of learning new tricks. Chin up, and persevere. For all the playing around with it is very much worth the headaches. The DVCS model(s) really are powerful time amplifying tools, of which Fossil clearly is the least nonsense, most purposeful winner. /blabbing For example, to experiment with some private changes to an actively developed codebase within a publicly cloneable Fossil project, one simply (honoring licenses, etc): 1. clones it 2. makes a branch 3. hacks 4. occasionally --pull from the official project; and merge with trunk 5. optionally publicly host this repository Now for some questions and observations... If the official project maintainers would like to bring in this branch onto their own Fossil server (either to simply host it, or to attempt a merge) they can do so with a --pull. However this currently would have the consequence of the all or nothing (wiki pages, other branches, tickets) behavior. Even so, having Fossil display and generate diffs so as to allow the changes of choice to be visualized and read clearly before being patched into a forked version (official or otherwise) is still about 1000:1 sanity improvement over emailing diff attachments. A project using Fossil may host some code with a F/OSS license of some kind, but it may or may not have as copyright holders granted the right to re-host things like wiki pages. So this detail would need to be considered before hosting a clone of someone else's project. Again some type of clone/push/pull granularity might be useful to avoid a legal, courtesy, or outright malicious incident. Consider the case of a new user who wants to try out your project. So they google your project name. The user unknowingly ends up at the site of some kid who had no intention infringing on your trademark, but was instead simply trying to give back their hack, for say - GPL compliance. (contrived, but you get the point) In the case of the Fossil project specifically, what sort of steps would make it ok to say hey folks check out fossil hack, it's up on a cloned repo at url abc. Even if one was in the position of a regular contributor, they still might want to do something like this as sort of a public private branch in between contribution worthy revisions. -- C. Thomas Stover Stover Enterprises, LLC ___ 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] applied DVCS for collaborative work - on the fossil project itself, or otherwise
On Thu, Dec 13, 2012 at 09:27:03AM -0700, Matt Welland wrote: One partial solution available today is to use http://chiselapp.com. Simply use their clone repo feature with regular pull. What is missing is a way to register the fork with the original project. It would be cool if it was possible to submit the URL of the forked repo to the parent. The parent can verify that the URL is a real fork and not some random URL and then make the forks (with description?) browseable on a Forks page. I like this, I should add the ability to easily fork chisel repositories. It would be easy to maintain the association and provide a page to show forks of projects. I'll add this to my chiselapp todo list. Thanks for the idea! -- 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?
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] applied DVCS for collaborative work - on the fossil project itself, or otherwise
On Thu, 13 Dec 2012 09:27:03 -0700 Matt Welland estifo...@gmail.com wrote: One partial solution available today is to use http://chiselapp.com. Simply use their clone repo feature with regular pull. What exactly does that do over a regular clone pull? -- www.thomasstover.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Local time zone detection and chroot
Hello, I'm running 'fossil serve' on a FreeBSD system in EST time zone. If I start the process as root, the Timeline setup page tells me that On this server, local time is currently the same as UTC, which is incorrect. If I start the process as some other user, such as www, then I get the correct -5 hour difference. The problem seems to be the chroot mechanism, which is only enabled for root. When a worker chroots to the repository location (e.g. /fossil), it loses access to /etc/localtime and /usr/share/zoneinfo/. This prevents SQLite from correctly detecting the current time zone. I got around the problem by doing a read-only nullfs mount from /usr/share/zoneinfo to /fossil/usr/share/zoneinfo, and then creating a symlink from ../usr/share/zoneinfo/America/New_York to /fossil/etc/localtime. In my case, /fossil is a separate file system, so I had to go through nullfs to avoid copying all the files and then forgetting to keep them updated. Just posting this for anyone else that runs into the same problem. Is there a simpler solution that would allow SQLite to correctly detect the time zone in a chroot? - Max ___ 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] applied DVCS for collaborative work - on the fossil project itself, or otherwise
On Thu, Dec 13, 2012 at 11:37 AM, C. Thomas Stover c...@thomasstover.comwrote: On Thu, 13 Dec 2012 09:27:03 -0700 Matt Welland estifo...@gmail.com wrote: One partial solution available today is to use http://chiselapp.com. Simply use their clone repo feature with regular pull. What exactly does that do over a regular clone pull? Nothing really except that chiselapp will regularly pull from the parent. The point I was trying to make is that using chiselapp you can create public forks quite easily. What was missing was a mechanism to aggregate or document the forks so that people looking at a repo can find them. James Turner has indicated that he is interested in adding such a mechanism into chiselapp which I think will be great. I also think that such a feature would be very beneficial if integrated into fossil itself. If I use chiselapp or my own private server to clone the fossil-scm.comsite there is no record of the fork at the fossil-scm site. I personally think that having pointers to forks of the project would potentially stimulate more development activity. Certainly I'd like to have that for my own projects. Being able to pull in just a single branch from one of those forks would be icing on the cake. -- www.thomasstover.com ___ 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
