>> 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 also would like this feature. (In my case, the command would appear to be "buildbot sendchange".) Hey, I think I can answer some of these questions! Richard's first. >How does the repository know when "code" has been pushed, >versus (say) wiki modifications or new tickets or other >artifacts? It doesn't care. There's no need for it to distinguish between those types of push, it just triggers the hook regardless. Whatever's hooked can deal with that. >What if two or more code changes are pushed at once? Then the post-commit hook is triggered multiple times. Let the hook target deal with it. >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. Interesting. That explains a few things. > Does the callback get invoked on each partial update? No. > Or does it wait until the complete update is received? Yes. >How does the server know when the update is complete? By calling the hook function at the end of the update code. Now Eric's questions. >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? It doesn't care. If the hooked resource isn't available, the hook code does nothing. > For checkins on what branches? Doesn't care. The hook target can deal with that. >How does it get out of its chroot jail? Assuming it's even in one. If it is, the hook target will obviously need to be inside the jail with it. (Maybe it's sash running a script.) If not, no problem. >What does it do if whatever it runs returns an error? Emit a warning maybe. Write a line to the log file. Discussion is needed on this point. >I am not saying that what is asked for is unreasonable, > just that it is not a job for Fossil itself. We agree that Fossil should do the minimum required work. I don't think a simple (and I do mean simple) post-sync hook is excessive. Hopefully I'll be able to prove it with patches. Another Eric (or the same one maybe, apologies): >Not, I suspect, without completely re-designing it, and >since it is one of the things that makes Fossil be Fossil... I admit I haven't looked at the code yet, but would inserting a few lines of code really constitute a complete re-design? I suspect not, unless somehow Fossil is dependent on to-the-nanosecond timing of its sync function. Wolfgang: >ANother problem, based on the distributed nature of >fossil, is the possible existence of forks! Surely this is taken care of by the sync itself? I don't think the hook needs to care about the consistency of the repository, only that *something* has changed. Yusuf: >I definitely value Fossil's leanness, and don't wish >to add a bunch of code for yet another feature, but >the ability to trigger a script would be useful and >shouldn't require much code. > >Anyways, I'll implement it for myself for now. Thanks >everyone for the technical suggestions. Made any progress yet, Yusuf? I'd be interested to see your patches. Kyle: >What about hooking into the process_one_web_page >function? That's probably something for the hook target to worry about. It can do screen-scraping if it wants. That sort of thing *would* bloat Fossil, and no-one wants that. If you got this far, thanks for reading. ;) Of course, now I'll go read the Sync doc and the source and prove the task impossible... Regards, Adam J Richardson _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
