[fossil-users] Bug with artifact clusters
Hello, I have one rather large repository (more than 600Mb) that contains a lot of relatively small text files as well as a significant number of jpg pictures. I have a fossil server on a NAS and two different pc that synchronize this repo directly with it. The problem I frequently run into is that after I push some commits from one pc, which show up fine in the timeline on the NAS repository, those commits don't show up on the other PC after fossil sync. It turns out that the corresponding artifacts aren't sent by the server to the second PC. After digging for a bit, it turns out that those artifacts, on the server, were neither in the unclustered table nor among the clusters (fossil test-clusters reported many clusters as unreachable). Doing fossil rebuild --clusters on the server fixes it, but the problem happens again from times to times. Did anyone else run into similar issues? Sending a copy of the repository to Richard Hipp for further investigation isn't really feasible given it's size. I don't mind trying to debug it myself, but I would be grateful for any pointer as to where to begin. As I understand it, freshly received artifacts are placed in the unclustered table and then later clustered during subsequent sync operations of their number exceed 100. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Core Dump in Shared Hosting
Hi, I'm new to Fossil SCM. I'm trying to install the lastest binaries for linux in a shared hosting account. I've ssh access, but wheh I'm try to execute ./fossil (755 chmoded) a core dump is generated. I cannot build from sources, have no access to cc nor gcc in this account. The same happens with the previus binary release. What else can I try before giving up? Exceuse my english, thanks in advance ___ 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] Core Dump in Shared Hosting
On Fri, Aug 17, 2012 at 11:17 PM, José Romero wrote: > Hi, I'm new to Fossil SCM. I'm trying to install the lastest binaries for > linux in a shared hosting account. I've ssh access, but wheh I'm try to > execute ./fossil (755 chmoded) a core dump is generated. I cannot build Unfortunately, the Linux world is not one-size-fits-all when it comes to binaries (sometimes not even static ones). What OS and kernel version are your host running? What bit-size is it (32 or 64)? Have you got the right binary for that bit size? What does the output of "ldd fossil" say? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Core Dump in Shared Hosting
On Fri, Aug 17, 2012 at 4:50 PM, Stephan Beal wrote: > On Fri, Aug 17, 2012 at 11:17 PM, José Romero wrote: > >> Hi, I'm new to Fossil SCM. I'm trying to install the lastest binaries for >> linux in a shared hosting account. I've ssh access, but wheh I'm try to >> execute ./fossil (755 chmoded) a core dump is generated. I cannot build > > > Unfortunately, the Linux world is not one-size-fits-all when it comes to > binaries (sometimes not even static onesWhat OS and kernel version are your > host running? What bit-size is it (32 or 64)? Have you got the right binary > for that bit size? What does the output of "ldd fossil" say? > ldd fossil statically linked uname -a Linux server-**.***.com 2.6.18-408.8.2.el5.lve0.8.61.3 #1 SMP Wed Jul 11 06:49:35 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux Maybe the 32bit binary in a 64bit OS is the problem, do you think so? > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > > > ___ > 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] Core Dump in Shared Hosting
On Fri, Aug 17, 2012 at 11:27 PM, José Romero wrote: > Maybe the 32bit binary in a 64bit OS is the problem, do you think so? > i have no idea - i can't remember the last time i copied a binary from one system to another non-identical system. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] API?
Hi Folks, Is there any kind of RESTful API for accessing Fossil repositories? Thanks, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ 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] API?
n Sat, Aug 18, 2012 at 1:31 AM, Miles Fidelman wrote: > Hi Folks, > > Is there any kind of RESTful API for accessing Fossil repositories? > https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view That's about the closest thing there is. It's not REST, but it's REST-ish (JSON-over-(HTTP-or-file). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] API?
Stephan Beal wrote: n Sat, Aug 18, 2012 at 1:31 AM, Miles Fidelman mailto:mfidel...@meetinghouse.net>> wrote: Hi Folks, Is there any kind of RESTful API for accessing Fossil repositories? https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view That's about the closest thing there is. It's not REST, but it's REST-ish (JSON-over-(HTTP-or-file). Thanks! -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ 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] API?
On Fri, Aug 17, 2012 at 7:03 PM, Stephan Beal wrote: > On Sat, Aug 18, 2012 at 1:31 AM, Miles Fidelman > wrote: >> Is there any kind of RESTful API for accessing Fossil repositories? > > https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view That's very nice. Thanks! > That's about the closest thing there is. It's not REST, but it's REST-ish > (JSON-over-(HTTP-or-file). What's not RESTful about it? At first glance I see it uses GET and POST appropriately, not using GET to create things, using POST to create/modify things. It doesn't use DELETE, but then that's because Fossil deletes nothing, right? As for PUT... POST for creating resources seems to be more popular now. That leaves the non-use of HTTP status codes, IIUC. But I do think that HTTP status codes should be used, and it's OK to deliver more application-specific status codes in the response entity. Nico -- ___ 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] API?
On Sat, Aug 18, 2012 at 5:17 AM, Nico Williams wrote: > That's very nice. Thanks! > :-D > What's not RESTful about it? At first glance I see it uses GET and > POST appropriately, not using GET to create things, using POST to > create/modify things. It doesn't use DELETE, but then that's because > Fossil deletes nothing, right? As for PUT... POST for creating > resources seems to be more popular now. That leaves the non-use of > HTTP status codes, IIUC. But I do think that HTTP status codes should > be used, and it's OK to deliver more application-specific status codes > in the response entity. > It's probably splitting hairs, but by the Wikipedia definition of REST, the JSON API is not REST, and i caught some flak for calling it a REST API early on in the development. Aside from the use of HTTP result codes (which i despise), CGI (which fossil uses even for built-in server mode) does not specify PUT, which REST does. So it's officially "not REST" ;). But yeah, it's REST-enough, IMO. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] API?
On Fri, Aug 17, 2012 at 10:26 PM, Stephan Beal wrote: > On Sat, Aug 18, 2012 at 5:17 AM, Nico Williams > wrote: >> What's not RESTful about it? At first glance I see it uses GET and >> POST appropriately, not using GET to create things, using POST to >> create/modify things. It doesn't use DELETE, but then that's because >> Fossil deletes nothing, right? As for PUT... POST for creating >> resources seems to be more popular now. That leaves the non-use of >> HTTP status codes, IIUC. But I do think that HTTP status codes should >> be used, and it's OK to deliver more application-specific status codes >> in the response entity. > > > It's probably splitting hairs, but by the Wikipedia definition of REST, the > JSON API is not REST, and i caught some flak for calling it a REST API early > on in the development. Aside from the use of HTTP result codes (which i > despise), CGI (which fossil uses even for built-in server mode) does not > specify PUT, which REST does. So it's officially "not REST" ;). But yeah, > it's REST-enough, IMO. Given that PUT is for replacing PUT has no more place in a Fossil RESTful API than DELETE. That leaves the non-use of HTTP result codes. But what's the problem with returning both, an HTTP status code and an application-specific one in the response entity? Doing so would leave you with a RESTful API and your clients can just ignore the HTTP result codes. Let's put it this way. To return 200 for a POST that actually failed is very strange -- the response entity had better, at the very least, not be cacheable if you'll do that. Nico -- ___ 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] API?
On Sat, Aug 18, 2012 at 5:45 AM, Nico Williams wrote: > codes. But what's the problem with returning both, an HTTP status > code and an application-specific one in the response entity? Doing so > would leave you with a RESTful API and your clients can just ignore > the HTTP result codes. > It just happened to accidentally evolve to the current mechanism because my JSON-centric apps catch connection-level errors (HTTP codes) at a lower level than app errors (response envelope code), and handle them differently (app errors tend to give me more detailed info). It's just more flexible that way in my experience. Let's put it this way. To return 200 for a POST that actually failed > is very strange -- the response entity had better, at the very least, > not be cacheable if you'll do that. > i would hope that no POSTs are cacheable :/. If the HTTP POST itself succeeds then yes, the JSON API will return an HTTP 200. If the app-specific JSON logic goes sideways, then that's an app-level error and that is reported via the envelope. i understand the arguments for using non-200 codes here, but i fundamentally feel that mixing app/transport error codes is is "just wrong," at least for this reason: the current approach allows us to pipe in json from any source and send it to any destination with exactly the same error-reporting semantics. That cannot be done if the API is tied to HTTP result codes. i have demo code which uses the Rhino JS engine (implemented in Java) to pipe JSON data to/from the stdin/stdout of a local Fossil binary, but the details of that transport are hidden away from the JS client, who uses the app-level API (which lives on top of the swappable connection-level API). See ajax/i-test/*.* for the details. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] API?
On Fri, Aug 17, 2012 at 11:24 PM, Stephan Beal wrote: >> Let's put it this way. To return 200 for a POST that actually failed >> is very strange -- the response entity had better, at the very least, >> not be cacheable if you'll do that. Arg, I meant 201 code. > i would hope that no POSTs are cacheable :/. If the HTTP POST itself 201s should be cacheable though, since a new entity is returned. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
