[fossil-users] Current status on hooks?
Hi, I'd like to know where we are in the topic of hooks. Their lack is one of the major setbacks of using Fossil. The last time I've noticed a discussion on their topic it was said, that it's blocked by inability to start background processes on Windows. Now there is a way to run Fossil itself in background on Windows. Has this helped towards getting hooks into main line? Kind regards, Remigiusz Modrzejewski ___ 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] Current status on hooks?
On Sat, Sep 10, 2011 at 10:32 AM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: Hi, I'd like to know where we are in the topic of hooks. Their lack is one of the major setbacks of using Fossil. The last time I've noticed a discussion on their topic it was said, that it's blocked by inability to start background processes on Windows. Now there is a way to run Fossil itself in background on Windows. Has this helped towards getting hooks into main line? The current limiting factor is DRH bandwidth. I have way too much else going on and this is a low priority issue for me. But you can help by contributing code! The hook mechanism should include a delay. This is because client-to-server push operations can occur in multiple stateless steps, and we really want to wait and run the hooks after all steps of the push operation are complete. So, for example, after the first push step, the server says to itself I'm going to run the hooks if I don't get any new information within 15 seconds. Then as additional rounds of push arrive, the counter is reset. The 15-second wait interval should be configurable. As part of the hook mechanism, I think we also need auto-sync between server instances. For example, Fossil itself is stored on three separate servers: http://www.fossil-scm.org/ in Dallas, http://www2.fossil-scm.org/ in New York, and http://www3.fossil-scm.org/ in Fremont. I currently keep these all in sync by setting a cron job to run sync every couple of hours. But it would be much better if one could enter, on each server, the names of other servers with which it should automatically synchronize whenever new information arrives. This auto-sync should be smart about avoiding sync-loops. Hence if server A gets new content and then auto-syncs to server B, server B should know that it got its new information from A and should avoid auto-syncing back to server A. Some other projects (besides hooks) that I think would be good to work on, for anybody who is interested: (1) Making Fossil more RESTful, and adding JSON replies. Stephan Beal is already working on this, but I'm sure he'd like to have collaborators. (2) Add the ability to push/pull/sync just a specific branch, as an alternative to the current behavior of push/pull/sync of everything. The current behavior should continue as the default. Single-branch push/pull/sync should be a command-line option. (3) Use the FTS4 full-text search engine of SQLite to implement full-text search over the entire repository history. Kind regards, Remigiusz Modrzejewski ___ 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] Current status on hooks?
On Sep 10, 2011, at 7:53 PM, Richard Hipp wrote: (3) Use the FTS4 full-text search engine of SQLite to implement full-text search over the entire repository history. Ha, that was the next thing I was going to ask ;) But unfortunately I'm unable to contribute any programming time this month :( Kind regards, Remigiusz Modrzejewski ___ 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] Current status on hooks?
On Sat, Sep 10, 2011 at 1:53 PM, Richard Hipp d...@sqlite.org wrote: The hook mechanism should include a delay. This is because client-to-server push operations can occur in multiple stateless steps, and we really want to wait and run the hooks after all steps of the push operation are complete. So, for example, after the first push step, the server says to itself I'm going to run the hooks if I don't get any new information within 15 seconds. Then as additional rounds of push arrive, the counter is reset. The 15-second wait interval should be configurable. I assume that similar logic would apply for running pre-hooks - ie, the pre hook is run only for the initial step of an operation. As part of the hook mechanism, I think we also need auto-sync between server instances. I have actually been looking into this, though not yet written any code. But now, I think I can put more time into this. ___ 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] Current status on hooks?
On Sat, 10 Sep 2011, Richard Hipp wrote: The hook mechanism should include a delay. This is because client-to-server push operations can occur in multiple stateless steps, and we really want to wait and run the hooks after all steps of the push operation are complete. So, for example, after the first push step, the server says to itself I'm going to run the hooks if I don't get any new information within 15 seconds. Then as additional rounds of push arrive, the counter is reset. The 15-second wait interval should be configurable. I don't like timers like that, a single server may have clients on fast connections 50 feet away, and at the end of a slow intercontinental link, so setting the timer correctly is about impossible. On top of that: they'll be hard to implement for cgi or inetd based servers, where nothing is running unless a client has an open connection. It's been a while since I looked at the protocol specs, but the client usually maintains (implicit) state in this type of protocol, and could very well indicate to the server that a push operation step is the first one (for a pre-commit hook), last one (for a post-commit hook), or both, which could then trigger the hooks immediately. Downsides: - needs a protocol change - what do you do if the last step never arrives? Gé___ 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] Current status on hooks?
On Sat, Sep 10, 2011 at 7:53 PM, Richard Hipp d...@sqlite.org wrote: (1) Making Fossil more RESTful, and adding JSON replies. Stephan Beal is already working on this, but I'm sure he'd like to have collaborators. +1 on that second part :). i made fairly good progress on this on Thursday/Friday. Today i'm taking a break to ease my aching elbow. A live demo of what currently works can be found here: http://fossil.wanderinghorse.net/repos/fossil-sgb/json/ -- - 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] Current status on hooks?
On Sat, Sep 10, 2011 at 4:49 PM, Gé Weijers g...@weijers.org wrote: I don't like timers like that, a single server may have clients on fast... It's been a while since I looked at the protocol specs, but the client usually maintains (implicit) state in this type of protocol, and could very well indicate to the server that a push operation step is the first one (for a pre-commit hook), last one (for a post-commit hook), or both, which could then trigger the hooks immediately. Downsides: - needs a protocol change - what do you do if the last step never arrives? In term so f invoking the post hook, I think a timer would be needed. ___ 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] Current status on hooks?
On Sun, Sep 11, 2011 at 12:26 AM, Ron Wilson ronw.m...@gmail.com wrote: In term so f invoking the post hook, I think a timer would be needed. That can't work in CGI mode, though, only in server mode and only if you don't kill the server after committing. :/ One of the big hurdles in implementing triggers, i think, has been platform portability. Now that jimtcl is part of the source tree, if it were integrated into fossil (e.g. as a replacement for the more limited th1), then triggers could be based off of jimtcl and run as part of the commit process both in CGI and server modes. In theory, anyway. -- - 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] Current status on hooks?
On Sun, Sep 11, 2011 at 12:54 AM, Stephan Beal sgb...@googlemail.comwrote: One of the big hurdles in implementing triggers, i think, has been platform portability. s/triggers/hooks/g -- - 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
