[fossil-users] autobuild
Hi, I have a need to build a repository once it's checked in. A handy feature would be to trigger a script (i.e., ant build_repo1.xml) once code is pushed to the server for a particular repository. It should not be a large change; if it's not in, shall I add it? ___ 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] autobuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/14/2010 11:50 AM, Yusuf X wrote: Hi, I have a need to build a repository once it's checked in. A handy feature would be to trigger a script (i.e., ant build_repo1.xml) once code is pushed to the server for a particular repository. It should not be a large change; if it's not in, shall I add it? ___ I wonder if this could be generalized into a hooks mechanism? Maybe shell scripts are stored as repository-specific configuration, then run on specific events (sync, pull, push, etc.) But that's probably something that should be discussed, if only to standardize on event types. I could see how something like this could open up a whole bunch of opportunities for third party functionality--post-commit emails to lists, emails to folks interested in following tickets (just pull the data out of the database), CI, etc. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyPqIsACgkQIaMjFWMehWIZDgCZAerADXB+AXidua7li+Yh5wQA IVQAnjJAXKXYVPPqV1P9CNdtM8iq2S1l =+6t+ -END PGP SIGNATURE- ___ 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] autobuild
On Tue, Sep 14, 2010 at 12:50 PM, Yusuf X ys1...@gmail.com wrote: Hi, I have a need to build a repository once it's checked in. A handy feature would be to trigger a script (i.e., ant build_repo1.xml) once code is pushed to the server for a particular repository. It should not be a large change; if it's not in, shall I add it? Additional information about the Fossil sync protocol is here: http://www.fossil-scm.org/fossil/doc/tip/www/sync.wiki You can get a better idea of how sync works by reading the Overview section. With that in mind: How does the repository know when code has been pushed, versus (say) wiki modifications or new tickets or other artifacts? What if two or more code changes are pushed at once? When a push occurs, the client makes multiple round-trip requests to the server, pushing a number of artifacts on each push. Just to keep the size of HTTP manageable, the client will split a push up into multiple round-trips if there are multiple files that have changed and the change sets (which are a binary xdelta) exceeds a size threshold. Does the callback get invoked on each partial update? Or does it wait until the complete update is received? How does the server know when the update is complete? ___ 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] autobuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/14/2010 12:55 PM, Eric wrote: Even if a repository knows what to do and how to do it, how does it know it is the repository that is supposed to do it? For checkins on what branches? I'd guess the same way it knows what its users and their passwords are. Isn't that the purpose of not pushing local configuration unless explicitly asked to do so? How does it get out of its chroot jail? What does it do if whatever it runs returns an error? Those are issues for the hook developer, I'd think. Set up a reasonable chroot jail that includes what is necessary. Handle exit codes and perform some reasonable action when one is received. I don't think that anyone is asking for Fossil to hold their hand through every possible contingency or thing that might go wrong, just to offer the capability to extend. I am not saying that what is asked for is unreasonable, just that it is not a job for Fossil itself. Fossil should do what it does. If you want something different for your developers/contributors, write a wrapper application. If you want something done on a repository server, write an independent program that reads the repository database at intervals - scheduled or a polling daemon. That's certainly an option, however given the general trend toward push rather than pull in many areas, I'm trying to think of ways for Fossil to notify other entities that something has changed rather than requiring extensions to periodically poll the DB, fetch the feed, etc. If embedded scripts aren't that way then so be it, but I still think there should be some means of push notification to external sources. I understand that the sync protocol currently doesn't support such a thing, so I wonder if it might be made to do so in the future, or if there may be some other mechanism by which this could be accomplished? I understand the desire to not introduce unnecessary complexity, so I'm curious as to the simplest thing to do that might make push notification work. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyPu18ACgkQIaMjFWMehWJGsACePh5AUWK+Wc9Xsncd9/yZYfNI NOQAn1ZIwy5FNyBXGAGaDOYQNn6XD95Z =srqp -END PGP SIGNATURE- ___ 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] autobuild
Yusuf X ys1...@... writes: Hi, I have a need to build a repository once it's checked in. A handy feature would be to trigger a script (i.e., ant build_repo1.xml) once code is pushed to the server for a particular repository. It should not be a large change; if it's not in, shall I add it? Hi ANother problem, based on the distributed nature of fossil, is the possible existence of forks! Maybe it would be a better way, to have a daemon, polling the fossil repo and forcing your action, when an event occurs. Therefor you can easyly ask timline.rss. This could be done for example with wget from the shell. best regards,Wolfgang ___ 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] autobuild
All of this gives me a headache. Talk about drifting away from the elegance of Fossil: distributed revision control with tickets and a wiki in a single binary. Let's get back to the original program, folks! You have so many other choices for bloatware :-) On Tue, Sep 14, 2010 at 1:19 PM, Wolfgang rat...@stumvolls.de wrote: Yusuf X ys1...@... writes: Hi, I have a need to build a repository once it's checked in. A handy feature would be to trigger a script (i.e., ant build_repo1.xml) once code is pushed to the server for a particular repository. It should not be a large change; if it's not in, shall I add it? Hi ANother problem, based on the distributed nature of fossil, is the possible existence of forks! Maybe it would be a better way, to have a daemon, polling the fossil repo and forcing your action, when an event occurs. Therefor you can easyly ask timline.rss. This could be done for example with wget from the shell. best regards,Wolfgang ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Michael Barrow michael at barrow dot me ___ 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] autobuild
On Tue, September 14, 2010 at 7:13 pm, Nolan Darilek wrote: ... I understand that the sync protocol currently doesn't support such a thing, so I wonder if it might be made to do so in the future, or if there may be some other mechanism by which this could be accomplished? Not, I suspect, without completely re-designing it, and since it is one of the things that makes Fossil be Fossil... I understand the desire to not introduce unnecessary complexity, so I'm curious as to the simplest thing to do that might make push notification work. Push notification is something of a myth. There has to be something there waiting to be pushed. It could be waiting on an event rather than polling, but then there has to be an event co-ordinator... Eric -- Eric Junkermann ___ 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] autobuild
On Sep 14, 2010, at 10:06:16 PDT, Richard Hipp wrote: On Tue, Sep 14, 2010 at 12:50 PM, Yusuf X ys1...@gmail.com wrote: Hi, I have a need to build a repository once it's checked in. A handy feature would be to trigger a script (i.e., ant build_repo1.xml) once code is pushed to the server for a particular repository. It should not be a large change; if it's not in, shall I add it? Additional information about the Fossil sync protocol is here: http://www.fossil-scm.org/fossil/doc/tip/www/sync.wiki You can get a better idea of how sync works by reading the Overview section. With that in mind: How does the repository know when code has been pushed, versus (say) wiki modifications or new tickets or other artifacts? What if two or more code changes are pushed at once? When a push occurs, the client makes multiple round-trip requests to the server, pushing a number of artifacts on each push. Just to keep the size of HTTP manageable, the client will split a push up into multiple round-trips if there are multiple files that have changed and the change sets (which are a binary xdelta) exceeds a size threshold. Does the callback get invoked on each partial update? Or does it wait until the complete update is received? How does the server know when the update is complete? What about hooking into the process_one_web_page function? Something like this: new_process_one_web_page: * remember timeline.rss state * previous process one web page functionality * If current timeline.rss state differs from remembered timeline.css state and a local notify command is set, call it with the full pathname to the repository That should be enough to let tools do whatever they need (they can check the timeline.css feed) without burdening fossil with a whole bunch of new logic. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
