[fossil-users] Horror story about git - Forever Alone
Morning, just read it today on Reddit: http://www.reddit.com/r/programming/comments/2hctgh/horror_story_about_git_forever_alone/ Article is at: http://thedailywtf.com/Articles/Forever-Alone.aspx What about Fossil in the same scenario? Sincerely, Gour -- From wherever the mind wanders due to its flickering and unsteady nature, one must certainly withdraw it and bring it back under the control of the self. ___ 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] gdiff/opendiff on os x: suppress unchanged files?
MessageWell, it may not seem like a problem if you compare a single file that you know has no differences, but imagine you’re checking a specific directory with hundreds of files, only one or two of which have changed. Fossil will invoke WinDiff and have you look at every single file in that directory, instead of the one or two that actually have changed. So, it IS kind of a problem, unless you avoid using WinDiff and use –tk option. From: dave Sent: Thursday, September 25, 2014 12:07 AM To: 'Fossil SCM user's discussion' Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress unchanged files? Oh, OK. Well, if I do, say C:\Experiments\libfossilfossil gdiff configure in my environment, I do indeed get a WinDiff on that file showing no changes, but isnt' that what I asked it to do, rather than not pop up WinDiff at all and make me think something is wrong? Oh, well, I guess I don't understand the particualr use-case, and probably I'm just adding noise to the conversation at this point, so I'll duck out. At least in the scenarios I described below, it seems to be working right to my sensibilities in at least version 1.29.___ 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] gdiff/opendiff on os x: suppress unchanged files?
Yes, that's exactly my use case, exacerbated by the fact that FileMerge/opendiff are real slow when used from fossil/git/bzr per file, taking on the order of seconds for every file it has to show, which doesn't happen when used from the GUI (radr #16400583 in bugreport.apple.com). Additionally opendiff CAN diff an entire directory, which would be the vastly preferrable use, offering the best interface, without the aforementioned per-file delay. Is gdiffing an entire directory something that could/should be added to fossil? I know at least one other gdiff tool that can do directories, though the name escapes me right now. On 25 September 2014 08:50, Tony Papadimitriou to...@acm.org wrote: Well, it may not seem like a problem if you compare a single file that you know has no differences, but imagine you’re checking a specific directory with hundreds of files, only one or two of which have changed. Fossil will invoke WinDiff and have you look at every single file in that directory, instead of the one or two that actually have changed. So, it IS kind of a problem, unless you avoid using WinDiff and use –tk option. From: dave Sent: Thursday, September 25, 2014 12:07 AM To: 'Fossil SCM user's discussion' Subject: Re: [fossil-users] gdiff/opendiff on os x: suppress unchanged files? Oh, OK. Well, if I do, say C:\Experiments\libfossilfossil gdiff configure in my environment, I do indeed get a WinDiff on that file showing no changes, but isnt' that what I asked it to do, rather than not pop up WinDiff at all and make me think something is wrong? Oh, well, I guess I don't understand the particualr use-case, and probably I'm just adding noise to the conversation at this point, so I'll duck out. At least in the scenarios I described below, it seems to be working right to my sensibilities in at least version 1.29. ___ 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] Horror story about git - Forever Alone
On 2014-09-25 08:44:04, Gour wrote: Morning, just read it today on Reddit: http://www.reddit.com/r/programming/comments/2hctgh/horror_story_about_git_forever_alone/ Article is at: http://thedailywtf.com/Articles/Forever-Alone.aspx What about Fossil in the same scenario? What's supposed to happen? The same thing. If you keep committing a binary file, changing it completely between each checkin, the repo's gonna become a fat thing. As you asked for it. This is in no way IMHO a GIT horror story. It's just a mild case of PEBKAC (who ended up quitting anyways), i.e., HR fckup. Regards, -Martin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Minor CAT command bug and LS command enhancement request
Hi, First, a minor bug in the CAT command (on Win machine): Using a backslash in the path does not find the file, while using a forward slash finds it. Second, would it be possible to add the -R repo_file option to the LS command? It'd be nice to get the list of files without opening the repo. Thanks. ___ 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] gdiff/opendiff on os x: suppress unchanged files?
Yep, now I understand and agree with you all. I guess you could call it supporting globbing, or scoped gdiff. I don't know if the present case is because globbing on the command line is expanded by the shell to a mondo list of files before fossil.exe gets them, in which case perhaps it needs a switch like --ignore-unchanged, or maybe changes it's behaviour to that automatically in the more-that-one-file case. Or maybe it always ignores unchanged files, but at least emits a message to stdout that it is skipping an unchangd file, so you don't think something is broken. I wonder if in the meantime a script could be created to take the output of fossil changes and concoct a file list of just the changed files, and then invoke fossil gdiff with that? OK, now I'm really going to duck out of the conversation. Haha. -dave -Original Message- Of Dömötör Gulyás ... Yes, that's exactly my use case, exacerbated by the fact that FileMerge/opendiff are real slow when used from fossil/git/bzr per file, taking on the order of seconds for every file it has to show, ... On 25 September 2014 08:50, Tony Papadimitriou to...@acm.org wrote: Well, it may not seem like a problem if you compare a single file that you know has no differences, but imagine youre checking a specific directory with hundreds of files, only one or two of which have changed. Fossil will ... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] case sensitivity fossil all list
Platform windows. Run: 1) fossil open ../fOSSIL/FossilBook.fossil 2) fossil close 3) fossil open ../FOSSIL/FossilBook.fossil 4) fossil close (note the changed case of 'F' ) 5) fossil all list output of 5th command : C:/temp/session5/fe/FOSSIL/FossilBook.fossil C:/temp/session5/fe/fOSSIL/FossilBook.fossil Even though I have a single repo, fossil reports I have 2. I think this could cause issues later. ___ 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] case sensitivity fossil all list
On Thu, Sep 25, 2014 at 10:56 AM, Gaurav M. Bhandarkar gaurav.a...@gmail.com wrote: Platform windows. Run: 1) fossil open ../fOSSIL/FossilBook.fossil 2) fossil close 3) fossil open ../FOSSIL/FossilBook.fossil 4) fossil close (note the changed case of 'F' ) 5) fossil all list output of 5th command : C:/temp/session5/fe/FOSSIL/FossilBook.fossil C:/temp/session5/fe/fOSSIL/FossilBook.fossil Even though I have a single repo, fossil reports I have 2. I think this could cause issues later. I think that Joe already checked in a fix for this. Have you tried rebuilding from the latest sources on trunk to see if that clears the problem? -- 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] security notice for _potential_ problem with _some_ CGI-hosted repos
Hi, all, My mother just sent me this, bless her heart: http://www.wired.com/2014/09/internet-braces-crazy-shellshock-worm/ Management summary: CGI scripts which use bash (as opposed to /bin/sh, with the caveat that /bin/sh is an alias for bash on some systems) might _potentially_ be affected. Some of this article is downright FUD[1], some of it is not _necessarily_ FUD. i pass it on primarily because all my CGI Fossil repos (currently) use /bin/bash instead of /bin/sh (will be resolved momentarily). [1] = PHP does _not_ use bash to run scripts in any environment i've ever seen in 15 years of admin'ing PHP-using servers. (PHP has whole books' worth of other security problems, though, unrelated to this article. ;) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] security notice for _potential_ problem with _some_ CGI-hosted repos
On Thu, Sep 25, 2014 at 6:43 PM, Stephan Beal sgb...@googlemail.com wrote: Some of this article is downright FUD[1], some of it is not _necessarily_ FUD. i pass it on primarily because all my CGI Fossil repos (currently) use /bin/bash instead of /bin/sh (will be resolved momentarily). Actually... Fossil CGI scripts typically use the fossil binary directly, as opposed to a shell between the script and binary. So this is essentially a false alarm for most configs (the ones which follow the fossil setup docs) but might affect those with more elaborate CGI script setups. e.g. my ~40 repos all use #!/path/to/fossil. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] security notice for _potential_ problem with _some_ CGI-hosted repos
On Thu, Sep 25, 2014 at 12:46 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Sep 25, 2014 at 6:43 PM, Stephan Beal sgb...@googlemail.com wrote: Some of this article is downright FUD[1], some of it is not _necessarily_ FUD. i pass it on primarily because all my CGI Fossil repos (currently) use /bin/bash instead of /bin/sh (will be resolved momentarily). Actually... Fossil CGI scripts typically use the fossil binary directly, as opposed to a shell between the script and binary. So this is essentially a false alarm for most configs (the ones which follow the fossil setup docs) but might affect those with more elaborate CGI script setups. e.g. my ~40 repos all use #!/path/to/fossil. The Fossil binaries on the www.fossil-scm.org server run inside a chroot jail that omits both /bin/bash and /bin/sh. In fact, that chroot jail has very little in it at all. None of the standard system utilities. No shared libraries. No devices. Just a handful of statically linked binaries in /usr/bin for running desired services (such as Fossil) and the databases needed to support them. Hasn't that been the recommended practice for public-facing internet services for decades? -- 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] security notice for _potential_ problem with _some_ CGI-hosted repos
On Thu, Sep 25, 2014 at 7:10 PM, Richard Hipp d...@sqlite.org wrote: The Fossil binaries on the www.fossil-scm.org server run inside a chroot jail that omits both /bin/bash and /bin/sh. In fact, that chroot jail has very little in it at all. None of the standard system utilities. No shared libraries. No devices. Just a handful of statically linked binaries in /usr/bin for running desired services (such as Fossil) and the databases needed to support them. :-D Most of us don't have hosters where we can run standalone server processes, though :(. The news about this exploit seems to be making the rounds quickly - i've gotten no less than 3 notices about it from various family and colleagues in the past hour. Hasn't that been the recommended practice for public-facing internet services for decades? Those who agree to that question might end up inadvertently outing their age ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] security notice for _potential_ problem with _some_ CGI-hosted repos
On Thu, Sep 25, 2014 at 10:43 AM, Stephan Beal sgb...@googlemail.com wrote: My mother just sent me this, bless her heart: http://www.wired.com/2014/09/internet-braces-crazy-shellshock-worm/ Management summary: CGI scripts which use bash (as opposed to /bin/sh, with the caveat that /bin/sh is an alias for bash on some systems) might _potentially_ be affected. Some of this article is downright FUD[1], some of it is not _necessarily_ FUD. i pass it on primarily because all my CGI Fossil repos (currently) use /bin/bash instead of /bin/sh (will be resolved momentarily). [1] = PHP does _not_ use bash to run scripts in any environment i've ever seen in 15 years of admin'ing PHP-using servers. (PHP has whole books' worth of other security problems, though, unrelated to this article. ;) Thanks for sharing that. As it turns out I do use a couple of bash scripts behind a HTTP Basic secured site (so now script access until after authentication, and I am the only one with a username/password, at least for now). I'm not too worried about it, but it's good to know that I probably need to go do security updates on my server. -- Scott Robison ___ 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] gdiff/opendiff on os x: suppress unchanged files?
FYI I did try on a lark: fossil changes %1 | grep EDITED | cut -c12- - | xargs fossil gdiff Which almost did it. Except for the fact that 'fossil changes' does not support specifying a directory (or whether to recurse, or not), so this was ultimately was the same as a 'fossil gdiff', haha, just more circumlocutory. But... Maybe someone smarter than me can think of a filter before the 'xargs' that further reduces the file list to just the ones in the intended directory, and then you'd have it, I think. -dave -Original Message- From: dave [mailto:d...@ziggurat29.com] Sent: Thursday, September 25, 2014 8:37 AM To: 'Fossil SCM user's discussion' Subject: RE: [fossil-users] gdiff/opendiff on os x: suppress unchanged files? Yep, now I understand and agree with you all. I guess you could call it supporting globbing, or scoped gdiff. I don't know if the present case is because globbing on the command line is expanded by the shell to a mondo list of files before fossil.exe gets them, in which case perhaps it needs a switch like --ignore-unchanged, or maybe changes it's behaviour to that automatically in the more-that-one-file case. Or maybe it always ignores unchanged files, but at least emits a message to stdout that it is skipping an unchangd file, so you don't think something is broken. I wonder if in the meantime a script could be created to take the output of fossil changes and concoct a file list of just the changed files, and then invoke fossil gdiff with that? OK, now I'm really going to duck out of the conversation. Haha. -dave -Original Message- Of Dömötör Gulyás ... Yes, that's exactly my use case, exacerbated by the fact that FileMerge/opendiff are real slow when used from fossil/git/bzr per file, taking on the order of seconds for every file it has to show, ... On 25 September 2014 08:50, Tony Papadimitriou to...@acm.org wrote: Well, it may not seem like a problem if you compare a single file that you know has no differences, but imagine youre checking a specific directory with hundreds of files, only one or two of which have changed. Fossil will ... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
