Re: [fossil-users] fossil: out of memory
On Thu, Oct 06, 2011 at 06:42:07AM +0200, Jiri Navratil wrote: > I upgraded to > > This is fossil version 1.19 [080d27a6b2] 2011-10-05 08:00:00 UTC > > Not sure, what I shall do in gdb. So I have this. Please let me know, what > next I can trace. Sorry > > > fossil(2681) malloc: *** mmap(size=18446744067267100672) failed (error > code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > /Users/navratil/src/fossil/fossil: out of memory Type 'break malloc_error_break' in gdb, before 'run'. Regards, Lluís ___ 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] GUI client for Windows?
On Thu, Oct 6, 2011 at 3:01 AM, Gilles wrote: > Is there another client I should know about, free or commercial? > Nope. Fossil's monolithic design doesn't lend itself well to creating GUIs. We're in the process of providing a solution, though - the JSON API allows alternate GUIs/shells to be written for fossil, but it is not yet feature-complete. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] fossil should know to open up perms on a file prior to update if no write access.
On Wed, Oct 5, 2011 at 11:20 PM, Matt Welland wrote: > "fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for > writing" > > The remainder of the message confused the developer (and me for that > matter). > > chmod 0644 foo.txt :-? or rm? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 you should not shun
On 6 October 2011 02:48, Gé Weijers wrote: > > > On Wed, 5 Oct 2011, Michal Suchanek wrote: > >> And when you find an issue with a commit that is some way back in your >> personal branch it is more logical and easier to review your branch if >> you append the fix to the commit where it belongs logically or if you >> append it at the top of the history interspersed with some possibly >> unrelated changes? > > One of the downsides of rebasing is that the following workflow does present > problems: > > - develop & commit > - sync with upstream, rebase/commit > - test > - sync with upstream, rebase/commit and push > > The version you tested now no longer exists in the repository. This may not > be a big issue in some environments, but it may be a showstopper elsewhere > (where I work it is). > > If you have to use a Git repository in such an environment you end up using > hooks to log all updates, and block all forced updates (updates that edit > history). Otherwise one clueless developer can do serious damage. Most sane git workflows require that sync with upstream does not require forced updates. Some project have experimental branch that may but all else should update cleanly. You can always make a copy of your branch before you rebase so that you do have a copy. Thanks Michal ___ 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] fossil: out of memory
2011/10/6 Jiri Navratil > fossil(2681) malloc: *** mmap(size=18446744067267100672) failed (error > code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > /Users/navratil/src/fossil/fossil: out of memory > i'm going to make a huge guess here... mmap() is only used by the sqlite3 code, not fossil. The number being given to mmap() looks like an uninitialized 64-bit int. However, i double that sqlite3's testing procedures would allow such an obvious problem to slip through. However... in the past month i've run into similar mysterious crashes/behaviours right after re-compiling fossil (not often - only 2 or 3 times in hundreds of rebuilds), and it _appears_ to be that my make/dependency info occasionally gets confused and doesn't rebuild everything it should. The solution in such cases is just to 'make clean; make' _Perhaps_ something like this has happened to you? If you build fossil from sources, please try a clean rebuild. If you downloaded the binary then this is not what is happening to you. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] fossil: out of memory
On Thu, Oct 6, 2011 at 10:36 AM, Stephan Beal wrote: > bit int. However, i double that sqlite3's testing procedures would allow > such an obvious problem to slip through. > lol, that shows how embedded the word "double" is in my memory. It should be "doubt". -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] What's goning on ? why warnings ?
[ijse@~/Desktop/WorkTable/WatchWizard]$ fossil changes EDITED src/js/controller/AppController.js [ijse@~/Desktop/WorkTable/WatchWizard]$ (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead [5734:5734:3045468:ERROR:browser_main.cc(1022)] GLib-GObject: g_object_ref: assertion `object->ref_count > 0' failed (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead (exe:6061): Gdk-WARNING **: XID collision, trouble ahead [ijse@~/Desktop/WorkTable/WatchWizard]$ [ijse@~/Desktop/WorkTable/WatchWizard]$ [ijse@~/Desktop/WorkTable/WatchWizard]$ (exe:6061): Gdk-WARNING **: XID collision, trouble ahead [ijse@~/Desktop/WorkTable/WatchWizard]$ fossil changes EDITED src/js/AccApp.js EDITED src/js/controller/AppController.js EDITED src/js/module/utils.js [ijse@~/Desktop/WorkTable/WatchWizard]$ fossil ci src/js/module/utils.js -m "添加本地数据库存储操纵组件" Autosync: http://ijse@10.8.0.22:8084 Bytes Cards Artifacts Deltas Sent: 130 1 0 0 waiting for server... (exe:6061): Gdk-WARNING **: XID collision, trouble ahead I just run: fossil ui -P 8084 & Is it serious ? thanks for answer.___ 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] What's goning on ? why warnings ?
On Thu, Oct 06, 2011 at 05:22:35PM +0800, i wrote: > [ijse@~/Desktop/WorkTable/WatchWizard]$ fossil changes > EDITED src/js/controller/AppController.js > [ijse@~/Desktop/WorkTable/WatchWizard]$ > (exe:6061): Gdk-WARNING **: XID collision, trouble ahead This output is not from fossil. I bet it's from some X program you started in this terminal. ___ 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] fossil: out of memory
On Oct 6, 2011, at 10:36 , Stephan Beal wrote: > mmap() is only used by the sqlite3 code, not fossil. OS X uses mmap underneath when you do malloc for the large region. -- Dmitry Chestnykh ___ 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] GUI client for Windows?
On Thu, 6 Oct 2011 09:05:06 +0200, Stephan Beal wrote: >Nope. Fossil's monolithic design doesn't lend itself well to creating GUIs. >We're in the process of providing a solution, though - the JSON API allows >alternate GUIs/shells to be written for fossil, but it is not yet >feature-complete. Thanks for the info. Out of curiosity, what do you mean by "monolithic design", and why is it a problem to write a GUI? ___ 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] What's goning on ? why warnings ?
On Thu, 6 Oct 2011 11:27:27 +0200 Lluís Batlle i Rossell wrote: > > [ijse@~/Desktop/WorkTable/WatchWizard]$ fossil changes > > EDITED src/js/controller/AppController.js > > [ijse@~/Desktop/WorkTable/WatchWizard]$ > > (exe:6061): Gdk-WARNING **: XID collision, trouble ahead > > This output is not from fossil. I bet it's from some X program you > started in this terminal. A Gtk program, to be precise. Probably a web browser. ___ 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] GUI client for Windows?
On Thu, Oct 6, 2011 at 12:02 PM, Gilles wrote: > Thanks for the info. Out of curiosity, what do you mean by "monolithic > design", and why is it a problem to write a GUI? Fossil is a standalone application, not a C library of functionality. That means that in order to write a UI the only possibility you have is to parse the command-line output. Since fossil makes no guarantees about output format, it's basically impossible (or, long-term, futile) to try to create a UI in this way. This worked (barely) with CVS because CVS had well-defined output formats (where as fossil is more "free form" (which i happen to prefer, so that isn't a complaint)). The JSON API effectively adds a library interface (of a sort) to fossil, which allows other applications to call specific functions of fossil and get well-defined responses which are easily parsed (JSON format) and understood. For example, we can write a shell-like interface which communicates with a fossil instance over JSON, hiding the JSON bits from the user in the form of command-shell-style input and output. More infos about the JSON API (still incomplete, but can already do a good deal) can be found here: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?hl=en_US -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] What's goning on ? why warnings ?
On Thu, Oct 6, 2011 at 12:05 PM, Konstantin Khomoutov < flatw...@users.sourceforge.net> wrote: > > > (exe:6061): Gdk-WARNING **: XID collision, trouble ahead > ps -ef | grep -w 6061 should reveal which app it is. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] SSL: cannot connect to host www.fossil-scm.org:443
2011/10/6 Jiri Navratil > I'm back to port 443. I have to accept "Unknown SSL certificate". Sync is > working. Is Fingerprint all right? Accept always not save me before the same > questions. I have to find, how to avoid this "WARNING: Certificate doesn't > match the saved certificate for this host!" probably. > > Thank you, > Jiri > > fossil sync > Server:https://myn...@www.fossil-scm.org/fossil > Bytes Cards Artifacts Deltas > Sent:3132 66 0 0 > waiting for server... > Unknown SSL certificate: > > organizationName = sqlite.org > organizationalUnitName= Domain Control Validated > commonName= sqlite.org > That's a UCC - a Unified Communications Certificate - which should be also valid for fossil-scm.org (and sqlite.com, and two other domains, all hosted off of the same web-server.) Do we need to do something to the Fossil SSL implementation so that it can accept a UCC? > > Issued By: > > countryName = US > stateOrProvinceName = Arizona > localityName = Scottsdale > organizationName = GoDaddy.com, Inc. > organizationalUnitName= http://certificates.godaddy.com/repository > commonName= Go Daddy Secure Certification Authority > serialNumber = 07969287 > > SHA1 Fingerprint: > > 90 a0 0e e6 73 65 65 85 38 81 94 1f 6a 22 6c f7 80 d1 ee 0b > > WARNING: Certificate doesn't match the saved certificate for this host! > Either: > * verify the certificate is correct using the SHA1 fingerprint above > * use the global ssl-ca-location setting to specify your CA root >certificates list > > If you are not expecting this message, answer no and contact your server > administrator. > > Accept certificate [a=always/y/N]? a > Received:8371132 0 0 > Total network traffic: 1917 bytes sent, 3612 bytes received > > -- > Jiri Navratil > > 6. 10. 2011 v 4:06, Richard Hipp: > > > > 2011/10/5 Jiří Navrátil > >> Thank you very much. >> >> Based on your input, I used fossil remote-url to switch from port 443 to >> 80. Now I can sync. >> >> I will go back to port 443, when signed certificate will be available. I >> will report then result then. >> > > Please try it now and let me know how it goes. > > > >> >> Thank you, >> Jiri >> >> -- >> Jiri Navratil >> >> 4. 10. 2011 v 20:24, Konstantin Khomoutov: >> >> > On Tue, 4 Oct 2011 19:46:57 +0200 >> > Jiří Navrátil wrote: >> > >> >> I'm getting this output: >> >> >> >> openssl s_client -host www.fossil-scm.org -port 443 >> >> CONNECTED(0004) >> >> write:errno=54 >> >> >> >> not sure, which header file is applicable for me on OpenBSD >> > [...] >> > >> > I managed to find [1] which states that on your system 54 means >> > ECONNRESET, so you're facing the same issue I do. >> > >> > 1. http://fxr.watson.org/fxr/source/sys/errno.h?v=OPENBSD >> >> ___ >> 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 > > -- 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] GUI client for Windows?
On Thu, 6 Oct 2011 12:10:15 +0200, Stephan Beal wrote: >Fossil is a standalone application, not a C library of functionality. Thanks for the infos. I think there's a market for Fossil because it's so easy to install and use, so that anyone who needs to keep different versions of a file would have the need for it, not just developers per se. But for this to happen, there must have a simple GUI. I tried WinFossil, but had issues with it. Any timetable for your product? ___ 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] SSL: cannot connect to host www.fossil-scm.org:443
> Do we need to do something to the Fossil SSL implementation so that it can > accept a UCC? I don't think so. On my Ubuntu VM Fossil doesn't complain about certificate, just clones without any questions. It should be the same on Mac OS X 10.4-10.6. (On 10.7 OpenSSL no longer have root certificates, so it requires dumping certificates and setting 'ssl-ca-location' to the correct path in order to silence questions.) -- Dmitry Chestnykh ___ 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] What's goning on ? why warnings ?
Thanks everyone! I've found the problem: [ijse@/etc/init.d]$ ps -ef | grep -w 6061 ijse 6061 5734 23 09:49 pts/002:30:58 /opt/google/chrome/chrome --type=plugin --plugin-path=/opt/google/chrome/libgcflashplayer.so --lang=en-US --channel=5734.0xbb6d8210.1440464591 ijse 6077 6061 0 09:49 pts/000:00:00 [Adobe AIR Appli] ijse 12855 6061 0 19:31 pts/000:00:00 [Adobe AIR Appli] ijse 13251 2743 0 20:32 pts/000:00:00 grep -w 606 It should because I use chrome.___ 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] GUI client for Windows?
On Thu, Oct 6, 2011 at 1:56 PM, Gilles wrote: > I tried WinFossil, but had issues with it. > It's not WinFossil's fault - because fossil has no well-defined standards for output format, it is a futile exercise to create a UI around it. One of the niches the JSON API hopes to fill is as a communication channel for front-ends like that one. > Any timetable for your product? > The "most important" functionality is working already (see the doc link). i unfortunately can't give a timetable - i hack on it as the time/energy/desire allow for. If you're well-versed in C, i'd be happy to have another developer or 3 working on these bits :). There are some (a small few) features which we can't provide over JSON without some major workarounds and/or caveats. Namely binary data (which JSON cannot natively support), which means committing binary files this way will not be implemented, at least initially, and will have some significant limitations if it is ever implemented (e.g. the RAM cost of committing base64-encoded binary content in JSON form would be roughly 2-3x the original content size, so it would likely fail miserably for those people who think that having files >500MB in their repo is somehow a good idea). Live demo: http://fossil.wanderinghorse.net/repos/fossil-sgb/json/ The various buttons on that page give a good summary of what works right now (but note that the public demo user does not have full access, so some commands will tell you "access denied"). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] GUI client for Windows?
On Thu, 6 Oct 2011 15:04:48 +0200, Stephan Beal wrote: >The "most important" functionality is working already (see the doc link). i >unfortunately can't give a timetable - i hack on it as the >time/energy/desire allow for. If you're well-versed in C, i'd be happy to >have another developer or 3 working on these bits :). Thanks for the infos. Unfortunately I don't have the skills, but I'll keep an eye on the project :-) ___ 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] GUI client for Windows?
> I tried WinFossil, but had issues with it. > > Understanding that WinFossil isn't a finished solution yet, what issues did you have with it? I've used it frequently for commit/update/diff/checkout/sync/create/ui and those functions have all worked. I think Ingo would love more feedback, and I he has been very responsive whenever I've filed ___ 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] GUI client for Windows?
Ooops, pressed send a little early. Meant to finish "filed bug reports". On Thu, Oct 6, 2011 at 9:50 AM, Tomek Kott wrote: > > I tried WinFossil, but had issues with it. >> >> Understanding that WinFossil isn't a finished solution yet, what issues > did you have with it? I've used it frequently for > commit/update/diff/checkout/sync/create/ui and those functions have all > worked. I think Ingo would love more feedback, and I he has been very > responsive whenever I've filed > ___ 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] GUI client for Windows?
On Thu, 6 Oct 2011 09:50:26 -0400, Tomek Kott wrote: > what issues did you have with it? Maybe it's just that I didn't use it properly: Starting with a repo I opened with the CLI and is located at the root of the partition where I keep all the documents I work on (source code, HTML pages, etc.)... Repositories > Select Checkout : point to directory where checked out files are located : "Selected directory doesn't contain a fossil checkout." If I choose "C:\" instead, it seems to scan the whole drive, which takes for ever and freezes the UI. As I leave the repo open at all times and just run "commit" when I need to create a new revision, is it possible to have WinFossil work on checked out files although the repo was already opened through the CLI? ___ 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] GUI client for Windows?
On Thu, 06 Oct 2011 16:09:45 +0200, Gilles wrote: >If I choose "C:\" instead, it seems to scan the whole drive, which >takes for ever and freezes the UI. Also, it chokes when using some non-standard characters: "filename contains illegal characters: ... OS Cda [or] Mp3.ico" ___ 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] GUI client for Windows?
So the checkout issue I'm not sure about, because that's how I started using winfossil as well. I have two thoughts. By default, WinFossil looks for '.fsl' type extensions. This might be somehow screwing things up because it can't match what it expects the fossil repo to be named vs. what it is named. You can change that in WinFossil settings. The other (super long shot) is that you've renamed _FOSSIL_ to something else (i think this is possible at compile time). As for the illegal characters, I guess I haven't ran across that one. You should probably submit a bug for that one with Ingo. Fossil itself allows that kind of name, right? Tomek On Thu, Oct 6, 2011 at 10:26 AM, Gilles wrote: > On Thu, 06 Oct 2011 16:09:45 +0200, Gilles > wrote: > >If I choose "C:\" instead, it seems to scan the whole drive, which > >takes for ever and freezes the UI. > > Also, it chokes when using some non-standard characters: > > "filename contains illegal characters: ... OS Cda [or] Mp3.ico" > > ___ > 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] GUI client for Windows?
On Thu, Oct 6, 2011 at 9:04 AM, Stephan Beal wrote: > There are some (a small few) features which we can't provide over JSON > without some major workarounds and/or caveats. Namely binary data (which > JSON cannot natively support), which means committing binary files this way > will not be implemented, at least initially, and will have some significant > limitations if it is ever implemented (e.g. the RAM cost of committing > base64-encoded binary content in JSON form would be roughly 2-3x the > original content size, so it would likely fail miserably for those people > who think that having files >500MB in their repo is somehow a good idea). > > Hi Stephan, Do you know about "protocol buffers". I'm asking because I didn't know about them since recently. http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html Could this help in order to allow binaries and improve the serialization performance? --Erlis ___ 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] GUI client for Windows?
On Thu, 6 Oct 2011 10:30:46 -0400, Tomek Kott wrote: >So the checkout issue I'm not sure about, because that's how I started using >winfossil as well. I have two thoughts. By default, WinFossil looks for >'.fsl' type extensions. This might be somehow screwing things up because it >can't match what it expects the fossil repo to be named vs. what it is >named. You can change that in WinFossil settings. I did change the default extension from .fsl to .repo, but I was wondering how to use WinFossil on files that have been checked out by opening the repo using the CLI. I guess that's what Repo > Select checkout does? >The other (super long shot) is that you've renamed _FOSSIL_ to something >else (i think this is possible at compile time). No, I didn't mess with this :-) >As for the illegal characters, I guess I haven't ran across that one. You >should probably submit a bug for that one with Ingo. Fossil itself allows >that kind of name, right? I don't know, I haven't tried. I'll report this issue. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Linking to fossil.exe [Re: GUI client for Windows?]
Hi Stephan, All I've just realized that despite fossil is an executable it does not prevent if from exporting functions for other programs to use (at least on Windows, am not sure if this is possible on *nix). I've just made a simple test executable Prog1.exe that links to another executable Prog2.exe. You can run Prog2.exe normally (it has it's own main function), but also you can link to it and use the functions it exports. My Prog1.exe uses a test function from Prog2.exe. All works as a breeze! A quick look on wikipedia and PE format (http://en.wikipedia.org/wiki/Portable_Executable) shows that PE is somewhat related to a unix COFF format. Perhaps the same trick is possible on *nix platforms. I think that it would solve a lot of pain in creating JSON API. Best regards, Jacek 2011/10/6 Stephan Beal : > On Thu, Oct 6, 2011 at 12:02 PM, Gilles wrote: >> >> Thanks for the info. Out of curiosity, what do you mean by "monolithic >> design", and why is it a problem to write a GUI? > > Fossil is a standalone application, not a C library of functionality. That > means that in order to write a UI the only possibility you have is to parse > the command-line output. Since fossil makes no guarantees about output > format, it's basically impossible (or, long-term, futile) to try to create a > UI in this way. This worked (barely) with CVS because CVS had well-defined > output formats (where as fossil is more "free form" (which i happen to > prefer, so that isn't a complaint)). > The JSON API effectively adds a library interface (of a sort) to fossil, > which allows other applications to call specific functions of fossil and get > well-defined responses which are easily parsed (JSON format) and understood. > For example, we can write a shell-like interface which communicates with a > fossil instance over JSON, hiding the JSON bits from the user in the form of > command-shell-style input and output. > More infos about the JSON API (still incomplete, but can already do a good > deal) can be found here: > https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?hl=en_US > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] GUI client for Windows?
On Thu, Oct 6, 2011 at 10:55 AM, Gilles wrote: > On Thu, 6 Oct 2011 10:30:46 -0400, Tomek Kott > wrote: > >So the checkout issue I'm not sure about, because that's how I started > using > >winfossil as well. I have two thoughts. By default, WinFossil looks for > >'.fsl' type extensions. This might be somehow screwing things up because > it > >can't match what it expects the fossil repo to be named vs. what it is > >named. You can change that in WinFossil settings. > > I did change the default extension from .fsl to .repo, but I was > wondering how to use WinFossil on files that have been checked out by > opening the repo using the CLI. I guess that's what Repo > Select > checkout does? > > Yep, it should. It's worked for me for all of the repo's I've tried. You could always try closing the checkout and opening it with WinFossil instead. Are you using a relatively up to date version of fossil? I think WinFossil needs at least 1.18 or some such... If you are still having trouble, I do think Ingo is responsive, so you could always submit it as a bug, and see what insight Ingo has. Tomek ___ 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] Linking to fossil.exe [Re: GUI client for Windows?]
On Oct 6, 2011, at 16:59 , Jacek Cała wrote: > I've just realized that despite fossil is an executable it does not > prevent if from exporting functions for other programs to use (at > least on Windows, am not sure if this is possible on *nix). It doesn't matter how the program is linked. Fossil calls exit() when a function needs to fail, and it leaves it up to the OS to clean up allocated memory. -- Dmitry Chestnykh ___ 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] Linking to fossil.exe [Re: GUI client for Windows?]
2011/10/6 Jacek Cała > I've just made a simple test executable Prog1.exe that links to > another executable Prog2.exe. You can run Prog2.exe normally (it has > it's own main function), but also you can link to it and use the > functions it exports. My Prog1.exe uses a test function from > Prog2.exe. All works as a breeze! > LOL! i've been programming since my childhood and never thought of trying that. > A quick look on wikipedia and PE format > (http://en.wikipedia.org/wiki/Portable_Executable) shows that PE is > somewhat related to a unix COFF format. Perhaps the same trick is > possible on *nix platforms. I think that it would solve a lot of pain > in creating JSON API. > It wouldn't save much, if any, in this case. In writing the JSON API i often have to minorly refactor existing fossil functionality or change its visibility from static to non-static so that the json code can use it. More often than not i have to create separate impls for the JSON variant of a given call because the original variants generate output to stdout (which is absolutely taboo in JSON mode, and must be avoided at all costs because it would corrupt the output). If i were using fossil.exe as a library (of sorts) i couldn't do that - i would still be limited to the set of features which are not static. Whether or not a function in fossil is static is almost arbitrarily decided - if the function is only used in one file, it's typically static, else it is not static. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] GUI client for Windows?
On Thu, Oct 6, 2011 at 4:30 PM, Tomek Kott wrote: > As for the illegal characters, I guess I haven't ran across that one. You > should probably submit a bug for that one with Ingo. Fossil itself allows > that kind of name, right? > i'm fairly certain (but not entirely) that that error comes from fossil, not windows. Someone posted about it here a few weeks ago. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Linking to fossil.exe [Re: GUI client for Windows?]
2011/10/6 Stephan Beal : > 2011/10/6 Jacek Cała >> >> A quick look on wikipedia and PE format >> (http://en.wikipedia.org/wiki/Portable_Executable) shows that PE is >> somewhat related to a unix COFF format. Perhaps the same trick is >> possible on *nix platforms. I think that it would solve a lot of pain >> in creating JSON API. > > It wouldn't save much, if any, in this case. In writing the JSON API i often > have to minorly refactor existing fossil functionality or change its > visibility from static to non-static so that the json code can use it. More > often than not i have to create separate impls for the JSON variant of a > given call because the original variants generate output to stdout (which is > absolutely taboo in JSON mode, and must be avoided at all costs because it > would corrupt the output). If i were using fossil.exe as a library (of > sorts) i couldn't do that - i would still be limited to the set of features > which are not static. Whether or not a function in fossil is static is > almost arbitrarily decided - if the function is only used in one file, it's > typically static, else it is not static. Agree, however, I thought that JSON API was the solution for linking external apps to fossil, and hence having ability to call fossil directly would make the API redundant. But, obviously, the API may be needed for some other reasons as well. Nonetheless, I think that (at least for windows builds) exporting fossil functions for others to link to is a viable and valuable option. Regards, Jacek > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] GUI client for Windows?
On Thu, Oct 6, 2011 at 11:11 AM, Stephan Beal wrote: > On Thu, Oct 6, 2011 at 4:30 PM, Tomek Kott wrote: > >> As for the illegal characters, I guess I haven't ran across that one. You >> should probably submit a bug for that one with Ingo. Fossil itself allows >> that kind of name, right? >> > > i'm fairly certain (but not entirely) that that error comes from fossil, > not windows. Someone posted about it here a few weeks ago. > Fossil is fairly strict about the format of filenames - to try to avoid cross-platform issues and globbing issues. http://www.fossil-scm.org/fossil/artifact/79bed8df57b?ln=425 > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] Linking to fossil.exe [Re: GUI client for Windows?]
Is this too much hassle to improve the exec in this matter? As said @Stephan, I think that this option is much more viable than using any intermediaries like standard output/error, protocol buffers or JSON API. What do you think? I could spent a bit of my time and look at it if this is doable and anyone is interested. Cheers, Jacek 2011/10/6 Dmitry Chestnykh : > On Oct 6, 2011, at 16:59 , Jacek Cała wrote: > >> I've just realized that despite fossil is an executable it does not >> prevent if from exporting functions for other programs to use (at >> least on Windows, am not sure if this is possible on *nix). > > It doesn't matter how the program is linked. Fossil calls exit() when a > function needs to fail, and it leaves it up to the OS to clean up allocated > memory. > > -- > Dmitry Chestnykh > > ___ > 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] GUI client for Windows?
On Thu, Oct 6, 2011 at 4:47 PM, Erlis Vidal wrote: > Do you know about "protocol buffers". I'm asking because I didn't know > about them since recently. > > > http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html > Never heard of them. Thanks for the link :). > Could this help in order to allow binaries and improve the serialization > performance? > No idea just yet :). But i will take a look at that. One thing to remember is that JSON != JavaScript, meaning that if we include ANY algorithms for binary data, ALL clients which want to use fossil/json HAVE to implement those algorithms. e.g. if we decide on base64, ALL client languages have to support it if they want to use those features of the API. Because of this, i would like to stick "non-formatted" data where possible, falling back to non-JSON-specified algos only when absolutely necessary. My current thinking on binary is that it "probably should" be encoded the same way one encodes binary in sqlite: X'aabbccdd', i.e. a simple list of hex value pairs. The down-side is that it literally doubles the size, which means that those fossil users which version-control 500MB files (which is insane, IMO, but people do it) will have a memory cost of approximately 3x that file's size when turning the artifact into JSON (1x for the original copy and 2x for the X'...' encoding, and possibly even more for the underlying sqlite statement to/from that data). Try to commit a 2GB file and you can't - your machine (or the remote fossil server) will die with an OOM error. The up-side is that en/decoding it is absolutely trivial - even an absolute beginner could figure out how to encode/decode it and it can be done in any language which supports binary data (e.g. NOT in shell code, but in JS/Python/Perl/PHP/Java, etc). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] GUI client for Windows?
Take a look to protocol buffers. The implementation is not restricted only to java, c++, python. Other people are adding more languages... this gives you kind of "portability" -Erlis On Thu, Oct 6, 2011 at 11:19 AM, Stephan Beal wrote: > On Thu, Oct 6, 2011 at 4:47 PM, Erlis Vidal wrote: > >> Do you know about "protocol buffers". I'm asking because I didn't know >> about them since recently. >> >> >> http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html >> > > Never heard of them. Thanks for the link :). > > >> Could this help in order to allow binaries and improve the serialization >> performance? >> > > No idea just yet :). But i will take a look at that. > > One thing to remember is that JSON != JavaScript, meaning that if we > include ANY algorithms for binary data, ALL clients which want to use > fossil/json HAVE to implement those algorithms. e.g. if we decide on base64, > ALL client languages have to support it if they want to use those features > of the API. Because of this, i would like to stick "non-formatted" data > where possible, falling back to non-JSON-specified algos only when > absolutely necessary. > > My current thinking on binary is that it "probably should" be encoded the > same way one encodes binary in sqlite: X'aabbccdd', i.e. a simple list of > hex value pairs. The down-side is that it literally doubles the size, which > means that those fossil users which version-control 500MB files (which is > insane, IMO, but people do it) will have a memory cost of approximately 3x > that file's size when turning the artifact into JSON (1x for the original > copy and 2x for the X'...' encoding, and possibly even more for the > underlying sqlite statement to/from that data). Try to commit a 2GB file and > you can't - your machine (or the remote fossil server) will die with an OOM > error. The up-side is that en/decoding it is absolutely trivial - even an > absolute beginner could figure out how to encode/decode it and it can be > done in any language which supports binary data (e.g. NOT in shell code, but > in JS/Python/Perl/PHP/Java, etc). > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] Linking to fossil.exe [Re: GUI client for Windows?]
2011/10/6 Jacek Cała > Agree, however, I thought that JSON API was the solution for linking > Well, it's "a" solution, not "the" solution. But it's "the" only solution for the time being ;). > external apps to fossil, and hence having ability to call fossil > directly would make the API redundant. That is also my thinking. With this in place, a "librification" rewrite/refactor of fossil becomes "less necessary." (Though there are still certainly many good arguments for such a rewrite, but we've beaten that horse to death several times already, so this is not a call for comments on the topic ;).) i've learned through implementing the JSON API that this will actually give us a great many options i had never really considered. e.g. someone suggested reading POST data from a file/stdin in CLI mode. Adding that ability was easy to do (30 lines or so of code[1], plus some touch-ups in CLI argument-handling code in other places) and indeed gives us a new way to interact with a local fossil binary. i do not yet have it running, but i've started work on a prototype shell for fossil which uses this approach, calling either a local fossil binary or sending the commands to a remote repo. [1] = http://www.fossil-scm.org/index.html/artifact/00d07d18aa32de91151831823347836cd5015aa8?ln=1055-1080 -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Linking to fossil.exe [Re: GUI client for Windows?]
On Thu, Oct 06, 2011 at 04:18:27PM +0100, Jacek Cała wrote: > Is this too much hassle to improve the exec in this matter? As said > @Stephan, I think that this option is much more viable than using any > intermediaries like standard output/error, protocol buffers or JSON > API. What do you think? I could spent a bit of my time and look at it > if this is doable and anyone is interested. Well, it's not that easy, because it plays with fork() and exit(), in order to have simpler code (less cleanup, less heap maintenance, ...) Regards, Lluís > 2011/10/6 Dmitry Chestnykh : > > On Oct 6, 2011, at 16:59 , Jacek Cała wrote: > > > >> I've just realized that despite fossil is an executable it does not > >> prevent if from exporting functions for other programs to use (at > >> least on Windows, am not sure if this is possible on *nix). > > > > It doesn't matter how the program is linked. Fossil calls exit() when a > > function needs to fail, and it leaves it up to the OS to clean up allocated > > memory. > > > > -- > > Dmitry Chestnykh > > > > ___ > > fossil-users mailing list > > fossil-users@lists.fossil-scm.org > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] GUI client for Windows?
On Thu, 6 Oct 2011 11:31:16 -0400 Erlis Vidal wrote: > Take a look to protocol buffers. The implementation is not restricted > only to java, c++, python. Other people are adding more languages... > this gives you kind of "portability" Last time I checked GPB was implemented in the form of a C++ library. I think this is a no-go for Fossil. I suspect that BSON would be easier to use for this case. The available C implementation (from MongoDB) is licensed under Apache License, Version 2.0 so I'm not sure about direct inclusion, but the spec itself appears to be not so complicated so probably it can be just implemented specifically for Fossil. 1. http://bsonspec.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] GUI client for Windows?
On Thu, Oct 6, 2011 at 5:59 PM, Konstantin Khomoutov < flatw...@users.sourceforge.net> wrote: > Last time I checked GPB was implemented in the form of a C++ library. > Many C++ APIs can be used from C code, actually, as long as their C++-only functionality can be hidden behind an intermediary C-style API. > I think this is a no-go for Fossil. > I suspect that BSON would be easier to use for this case. > There was a HUGE (50+ message) thread on this on the JSON list a couple weeks back. As far as binary JSON goes, i like where this is going: http://ubjson.org/ But i'm still a long way from having to worry about that type of stuff right now. Once all of the text-mode features work (including checking in non-binary content) i'll try to tackle the binary problem. JSON does not have a mechanism for binary, so any solution either needs to circumvent JSON (e.g. using non-json HTTP requests) or introduce an encoding mechanism (which immediately rules out any client languages which cannot/do not have such algos). The available C implementation (from MongoDB) is licensed under Apache > License, Version 2.0 so I'm not sure about direct inclusion, but the > spec itself appears to be not so complicated so probably it can be just > implemented specifically for Fossil. > > >From what i've read about these so far, they're about the binary encoding of JSON values/trees, not the encoding of arbitrary binary data IN JSON (which is what we would need to support binary-using operations). bson also extends JSON with its own types, which is something i would much rather avoid (portability). At this moment google's protocol buffers look like a reasonable middle-ground. i do have ideas on how to solve "the too-large blob" problem, by taking the data via multiple chunks (this is how gmail sends attachments) and buffering them in a new table for a while (until the request completes or they expire and are cleaned up). But... i'm still a long way from having to tackle that problem (it is the absolutely last feature on my TODO list, and my TODO list is about as long my hair [1]). Another idea would be to reference binary data via URLs rather than transport them directly. e.g. a JSON-mode file checkout might return a URL which will directly pull that file (in raw form) from the repository, and then the client could fetch it using a binary-capable mechanism (wget for a shell client and a URLConnection in Java). Diffs and whatnot are a whole other problem altogether, because there are no clients other than fossil itself which handles fossil-format diffs. So those are also way, way down the list on the list of (potential) TODOs. [1] = with only a slight tilt of my head, i could[2] wipe my behind with it. [2] = but i don't! -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] GUI client for Windows?
On Thu, Oct 6, 2011 at 6:20 PM, Stephan Beal wrote: > Diffs and whatnot are a whole other problem altogether, because there are > no clients other than fossil itself which handles fossil-format diffs. > That's not true - fossil interacts with many graphical diff programs. > So those are also way, way down the list on the list of (potential) TODOs. > But that is still true ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] fossil should know to open up perms on a file prior to update if no write access.
On Thu, Oct 6, 2011 at 12:07 AM, Stephan Beal wrote: > On Wed, Oct 5, 2011 at 11:20 PM, Matt Welland wrote: > >> "fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for >> writing" >> >> The remainder of the message confused the developer (and me for that >> matter). >> >> > chmod 0644 foo.txt > > :-? > > or rm? > Of course it is easy to fix. But why expose your users to all the distracting and irrelevant junk in the error message? If possible report the fact that the file can't be opened and stop. The end user was confused by the message and resorted to asking me to figure it out and even I was confused by the message for a few minutes. My suggestion to fossil developers is to keep the errors from fossil clean and relevant. But it is only a suggestion. -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] fossil should know to open up perms on a file prior to update if no write access.
On Thu, Oct 6, 2011 at 6:28 PM, Matt Welland wrote: > Of course it is easy to fix. But why expose your users to all the > distracting and irrelevant junk in the error message? If possible report the > fact that the file can't be opened and stop. > > The end user was confused by the message and resorted to asking me to > figure it out and even I was confused by the message for a few minutes. > i would have been, too. > My suggestion to fossil developers is to keep the errors from fossil clean > and relevant. But it is only a suggestion. > If you can suggest a concrete solution, i'll take a look at implementing it. i'm not familiar with that particular code, so an immediate plan doesn't spring to mind. Can you do a mock-up fossil session which demonstrates what a user "should" see in that case? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] GUI client for Windows?
On Thu, 6 Oct 2011 18:20:12 +0200 Stephan Beal wrote: > > Last time I checked GPB was implemented in the form of a C++ > > library. > Many C++ APIs can be used from C code, actually, as long as their C+ > +-only functionality can be hidden behind an intermediary C-style API. My point is that we'll need to link against libstdc++ which is not a problem only on Windows where this library is guaranteed to be available (in the form of msvcrXYZ.dll files). ___ 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] fossil should know to open up perms on a file prior to update if no write access.
On Thu, Oct 6, 2011 at 9:32 AM, Stephan Beal wrote: > On Thu, Oct 6, 2011 at 6:28 PM, Matt Welland wrote: > >> Of course it is easy to fix. But why expose your users to all the >> distracting and irrelevant junk in the error message? If possible report the >> fact that the file can't be opened and stop. >> >> The end user was confused by the message and resorted to asking me to >> figure it out and even I was confused by the message for a few minutes. >> > > i would have been, too. > > >> My suggestion to fossil developers is to keep the errors from fossil clean >> and relevant. But it is only a suggestion. >> > > If you can suggest a concrete solution, i'll take a look at implementing > it. i'm not familiar with that particular code, so an immediate plan doesn't > spring to mind. Can you do a mock-up fossil session which demonstrates what > a user "should" see in that case? > **BEFORE** prompt> fossil update UPDATE foo.txt fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for writing Rolling back prior filesystem changes... UNDO foo.txt fossil: SQLITE_ERROR: near "redoflag": syntax error fossil: near "redoflag": syntax error UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT redoflag WHERE pathname='foo.txt' **AFTER** prompt> fossil update UPDATE foo.txt fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for writing Rolling back prior filesystem changes... prompt> > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > > ___ > 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] fossil should know to open up perms on a file prior to update if no write access.
On Thu, Oct 6, 2011 at 7:03 PM, Matt Welland wrote: > UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT > redoflag WHERE pathname='foo.txt' > what version are you using? The current code has a command between isLink=0 redoflag... db_prepare(&q, "UPDATE undo SET content=:c, existsflag=%d, isExe=%d, isLink=%d," " redoflag=NOT redoflag" " WHERE pathname=%Q", new_exists, new_exe, new_link, zPathname ); -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] fossil should know to open up perms on a file prior to update if no write access.
On Thu, Oct 6, 2011 at 7:21 PM, Stephan Beal wrote: > what version are you using? The current code has a command between isLink=0 > redoflag... > command == comma, of course -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] fossil should know to open up perms on a file prior to update if no write access.
On Wed, Oct 5, 2011 at 4:16 PM, Matt Welland wrote: > Rolling back prior filesystem changes... > UNDO foo.txt > fossil: SQLITE_ERROR: near "redoflag": syntax error > fossil: near "redoflag": syntax error > UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT > redoflag WHERE pathname='foo.txt' > The problem was fixed here: www.fossil-scm.org/fossil/ci/be956c3c88fd This fix should be in version 1.19. > > > > ___ > 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] fossil should know to open up perms on a file prior to update if no write access.
Ah, cool!! I assumed the SQLITE error was somehow related to the non-writablitiy of the file. I'll read more carefully and dig a little deeper next time so the feedback can be of higher quality. On Thu, Oct 6, 2011 at 10:27 AM, Richard Hipp wrote: > > > On Wed, Oct 5, 2011 at 4:16 PM, Matt Welland wrote: > >> Rolling back prior filesystem changes... >> UNDO foo.txt >> fossil: SQLITE_ERROR: near "redoflag": syntax error >> fossil: near "redoflag": syntax error >> UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT >> redoflag WHERE pathname='foo.txt' >> > > The problem was fixed here: > > www.fossil-scm.org/fossil/ci/be956c3c88fd > > This fix should be in version 1.19. > > > >> >> >> >> ___ >> 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] fossil should know to open up perms on a file prior to update if no write access.
Hmmm I have 1.19 but still see the problem since I built from source before it was released? It might be a little clearer to ensure the 1.19 is only in the files from the checkin prior to the release. chlr11723> fossil version This is fossil version 1.19 [24c16584cc] 2011-08-26 14:59:43 UTC But: chlr11723> strings ~/bin/fossil | grep 'UPDATE undo SET content' UPDATE undo SET content=:c, existsflag=%d, isExe=%d, isLink=%d redoflag=NOT redoflag WHERE pathname=%Q === BTW: I edited the binary (just replaced the space with a comma) and as expected it works fine: chlr11723> ./fossil update Autosync: file:///tmp/mrwellan/testing/test2.fossil Bytes Cards Artifacts Deltas Sent: 130 1 0 0 Received: 354 8 0 0 Total network traffic: 245 bytes sent, 445 bytes received UPDATE foo.txt ./fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for writing Rolling back prior filesystem changes... UNDO foo.txt chlr11723> On Thu, Oct 6, 2011 at 10:34 AM, Matt Welland wrote: > Ah, cool!! I assumed the SQLITE error was somehow related to the > non-writablitiy of the file. I'll read more carefully and dig a little > deeper next time so the feedback can be of higher quality. > > > On Thu, Oct 6, 2011 at 10:27 AM, Richard Hipp wrote: > >> >> >> On Wed, Oct 5, 2011 at 4:16 PM, Matt Welland wrote: >> >>> Rolling back prior filesystem changes... >>> UNDO foo.txt >>> fossil: SQLITE_ERROR: near "redoflag": syntax error >>> fossil: near "redoflag": syntax error >>> UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT >>> redoflag WHERE pathname='foo.txt' >>> >> >> The problem was fixed here: >> >> www.fossil-scm.org/fossil/ci/be956c3c88fd >> >> This fix should be in version 1.19. >> >> >> >>> >>> >>> >>> ___ >>> 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] fossil should know to open up perms on a file prior to update if no write access.
On Oct 6, 2011, at 19:03 , Matt Welland wrote: > fossil: SQLITE_ERROR: near "redoflag": syntax error > fossil: near "redoflag": syntax error > UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT > redoflag WHERE pathname='foo.txt' Is this from later trunk version? I fixed this error a few weeks before. -- Dmitry Chestnykh ___ 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] fossil should know to open up perms on a file prior to update if no write access.
On Thu, Oct 6, 2011 at 7:34 PM, Matt Welland wrote: > carefully and dig a little deeper next time so the feedback can be of > higher quality. LOL! That is quite possibly the best "please excuse me" i've ever seen posted on a list. That one's of put-it-on-a-t-shirt quality. :) -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] fossil should know to open up perms on a file prior to update if no write access.
On Oct 6, 2011, at 19:49 , Matt Welland wrote: > Hmmm I have 1.19 but still see the problem since I built from source > before it was released? It might be a little clearer to ensure the 1.19 is > only in the files from the checkin prior to the release. > > chlr11723> fossil version > This is fossil version 1.19 [24c16584cc] 2011-08-26 14:59:43 UTC The released version (from Downloads page) is: This is fossil version 1.19 [6517b5c857] 2011-09-01 18:25:19 UTC > BTW: I edited the binary (just replaced the space with a comma) and as > expected it works fine: Nice patch! :-) If you use symlinks, though, there are a few more fixes for them, so you may want to recompile from trunk. If not, I think this version is fine. -- Dmitry Chestnykh ___ 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] fossil should know to open up perms on a file prior to update if no write access.
On Thu, Oct 6, 2011 at 7:34 PM, Matt Welland wrote: > Ah, cool!! I assumed the SQLITE error was somehow related to the > non-writablitiy of the file. BTW: the file was not updated because fossil bailed out because of the SQL error. From a user's perspective, the SQL error might not have seemed fatal, and therefore not the source of the problem (i.e. your reaction was perfectly understandable, IMO), but fossil always "fails fast" - if you ever see it emit an error, then it aborted whatever it was trying to do (before it changes anything, more often than not, though a checkout could theoretically fail and still update some of the files). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] GUI client for Windows?
On Thu, 6 Oct 2011 11:01:43 -0400, Tomek Kott wrote: > Yep, it should. It's worked for me for all of the repo's I've tried. So I guess WinFossil doesn't work when the repo is opened at the root of a partition that contains a lot of directories because it will go through each one looking for files that are under source control... which can take a look time, and can even fail if a directory contains characters it doesn't like. >could always try closing the checkout and opening it with WinFossil instead. >Are you using a relatively up to date version of fossil? I think WinFossil >needs at least 1.18 or some such... Yes, I upgraded Fossil to the latest and greatest (1.19). >If you are still having trouble, I do think Ingo is responsive, so you could >always submit it as a bug, and see what insight Ingo has. I'll sum up the issues I'm having and create a few tickets. Thank you. ___ 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] GUI client for Windows?
On Thu, 6 Oct 2011 11:17:06 -0400, Richard Hipp wrote: >Fossil is fairly strict about the format of filenames - to try to avoid >cross-platform issues and globbing issues. >http://www.fossil-scm.org/fossil/artifact/79bed8df57b?ln=425 Thanks for the tip. ___ 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] git vs fossil again (was: why you should not shun)
+1.
Shunning a commit is a bad idea.
But fossil will not differentiate type of content when shunning so not sure if
it can prevent shunning a commit.
> - Original Message -
> From: Erlis Vidal
> Sent: 10/06/11 12:21 AM
> To: fossil-users@lists.fossil-scm.org
> Subject: Re: [fossil-users] git vs fossil again (was: why you should not
> shun)
>
> I get the two points of view and I'm not saying one is right or wrong.
> Modifying the history versus keeping everything as indeed happens (the
> history after all)
>
> Yesterday I was confused because I though the shun was done in the big file,
> but indeed the shun was done in the commit also... will that modify the
> history? I got the feeling that shunning a commit will change the history...
> not sure about it, you tell me.
>
> If I'm working under the premisses that the history cannot be changed, is
> shunning a commit (in case it change the history) a valid operation? Maybe
> fossil shouldn't allow to shun a commit, just individual files, if you
> really want to shun all files in that commit, then fossil could allow that,
> (shun --all) but that shouldn't touch ever the commit artifact..
>
> Regards,
> Erlis
>
> On Wed, Oct 5, 2011 at 2:40 PM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
>
> > On Wed, 5 Oct 2011 11:12:31 -0700
> > Mike Meyer wrote:
> >
> > > > That sort of "we don't need it, we don't need it" mantra is a
> > > > typical case of the famous "Blub paradox".
> > > > I mean, if we have two DVCS tools one of which makes you able to
> > > > rewrite history and another one which doesn't, the first one is more
> > > > powerful _in this particular respect_. It's as simple as that.
> > > > By supporting a feature, the tool does not force you to employ that
> > > > feature in your workflow.
> > > First, note that there is a difference between "rewriting history",
> > > which is what git supports, and "deleting unwanted items", which is
> > > the request that started this.
> > Correct.
> >
> > > Second, that a feature doesn't affect you if you "just don't use it"
> > > is a fallacy. Sure, I think history should be sacrosanct, so I won't
> > > use rebase even if it's available. That doesn't stop others on the
> > > project (who don't agree with me) from using it . The only way to
> > > make sure that doesn't happen is to not have the feature available
> > > *at all*.
> > I'm not entirely convinced.
> > Look at the workflow used by the Git team: they maintain the set of
> > well known branches, of which the only one, named "pu" ("proposed
> > updates"), is allowed to be rebased and that's actually what happens
> > with it each time the new release is made--it's cut from the master
> > afresh. I mean, while every committer has `git rebase` at their
> > disposal and knows how it works this does not mean they go off and break
> > the repository with rebases. So your point is only really valid when
> > the project is run by a bunch of idiots or complete newbies.
> >
> > > Finally, having a feature that powerful available tends to cause the
> > > API to *not* include safe versions of common tasks that that
> > > dangerous feature handles. To see what I mean, take a look at
> > > mercurial, which shares the fossil philosophy, but provides a
> > > (disabled by default) rebase command. It has a number of commands
> > > (*not* disabled by default) for tasks that are handled in git using
> > > rebase. Unlike rebase, those commands are safe, in that mistakes with
> > > them can't wreck your repo the way a mistake with rebase can. It may
> > > not make a difference if you never make mistakes, but in that case
> > > you don't need rebase.
> > Git handles it from the opposite direction by having "the reflog".
> > But I find this point to be valid, yes, safety nets are a must when it
> > comes to handling precious data. BTW I'm a fan of `fossil undo` for
> > that matter.
> >
> > > Bottom line: while "more features" may imply "more powerful", it
> > > doesn't imply "better".
> > Moot point.
> > I really miss Git's "index" and `git add --patch` here.
> > Is Fossil better than Git in this respect by not having those "more
> > features"? Surely it completely is in the eye of the beholder.
> > ___
> > 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
