On Mon, May 30, 2016 at 4:39 PM, John P. Rouillard <rouilj+fos...@cs.umb.edu > wrote: > > In message <38334f96-17cf-e32a-e758-2d15ce5fd...@cheshireeng.com>, > Ross Berteig writes: > >One of the hooks is "command_hook" which is invoked for every > >fossil command. That name can raise an error (or call break or > >continue) to prevent the fossil command from executing. > > > >Since the hook is called early, it knows the command name, its > >arguments, its flags, and not a lot lse. > > Well if the hook was executed, I could use it to reject a > --no-th-hooks, but ironically it would never see it 8-).
On any distributed VCS, hooks are like training wheels. They help the user follow process, but a determined user can take them off. I hadn't seen documentation on command_hook, but it does get executed before the list of files with changes is "calculated" so would have to (somehow) duplicate that functionality. However I would expect the server would run the hook on an > incoming commit. > > Hmm, now that I think about it, are all the hooks defined in the > "transfer"(xfersetup) admin page, so they are only run on the > client? I think the receiving server also runs hooks, but I don't know. I don't see where to configure the command_hook on any of the admin pages, but I'm using the 1.34 released version, not the latest development version. >The fossil -no-th-hooks option will skip all hooks for that > >command. Depending on what else you do in a hook, that might be > >more than you wanted. > > Yup. The embedded codeword allowed fine grain tuning of the > checks and also recorded whet the developer requested so s/he was > accountable for the bypass. If any client can disable hooks on > the remote central repo without any logging/accountability this > is all moot. Hooks can only be disabled locally. Of course, Fossil will have a record of the commit and who did it. So, you use an assumption of "bypassed unless proven otherwise". >>Is there some similar way to inspect the transferred artifacts > >>and file contents and roll back the commit? > > > >Nope. And there can't be. Nothing is transferred until well > >after the whole collection of artifacts that make up the commit > >have been created and safely stowed in the local > >repository. There is no "roll back" from that. > > Err, that's unfortunate. I was expecting that the order of operations > for a commit on the server (or a local repo) would be: > > open connection to client (or in the case of local file access, > just open the sqlite file) > When you run "fossil commit", Fossil is directly updating the database residing on you PC. If "auto-sync" is turned on, Fossil will automatically pull from the remote server before processing the commit, then automatically push to the remote server after processing the commit, but the commit process itself is local only. When a remote Fossil server receives a commit from your local repo, it could run its own commit hook. I don't know if does. Right now, as best I can tell, only a post_commit hook is available. I'm not sure all of the implications and collateral damage of a pre_commit hook on a receiving server. Fossil's current approach is to block all pushes from users not authorized to push. (Contributions from those users can, however, be pulled, in which case, Fossil records both who made te commit and who pulled the commit.) > start transaction in database [...] > commit transaction > Internally, "fossil commit" does this. It just doesn't have a hook just before committing the database transaction. However, on a receiving server, commit processing is much simpler. Overall it sounds that wrapping tools are required to support > process and validation with fossil rather than supporting the > process within fossil. > At least for "fossil commit", a workable pending_commit hook could be implemented. Though there is a complication: any commit that has a "base line" manifest (as opposed to "delta manifest") will list all "current" artifacts, not just those changed by the commit, so the hook would also need a way to get a list of artifacts for just the changed files.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
