On Apr 23, 2016, at 12:33 AM, Ron W <ronw.m...@gmail.com> wrote: > > Also, for us, almost all tickets are entered through the web interface. > Although Fossil's hooks feature works with tickets as well as with commits, > there is no mechanism to create a new branch from a hook script. >
I still have to grok all the TH1 script stuff to see what is possible with it. I was under the impression it is mostly useful for creating more dynamic web content, but if its possible to hook into commit actions and block them or ensure [nnnnnnnnnn] ticket numbers get added to commit comments, or when branches are created add tags automatically, etc…then I will definitely have a look at that. Anything that I can hide inside the server rather then depend on client side wrapper scripts would be preferable. > > Before Fossil, we were using a commercially available VCS that did force > doing development on branches, then merging to trunk, so we were already used > to doing that. > > Our work rules require that each of us take time each day to review pending > code changes. Most days, our integration person will have a few changes to > integrate, so not much time is required. If a problem comes up in > integration, that merge will be discarded and the issue related to the change > that failed integration will be marked "InDev". The person who worked on that > change set will then be responsible for fixing the problem in consultation > with the authors of the "conflicting" changes. +1 > As I said in my previous message, users' local repos can use either > "autosync=pullonly" or "don't-push", which will impede pushing changes to the > upstream (or main) repo - or any other repo. But, as I said, users can change > those settings. You would have to trust them to not do so with out a very > compelling reason. Yea, for various different reasons I think I would prefer if their changes go to the server on their own branch. But I will think about that pull only option to see if may make any sense here. > Alternately,Fossil does have provisions for "hooks". Currently, the hook > scripts have to be written in TH1 (which can have TCL expressions embedded in > it.) I have never done this, so I don't know how it works. I’d like to find some more out about TH1. I was under the impression from everything I read so far, that its mostly useful for creating dynamic web content, It was not obvious to me as of yet how it could be used to “hook” into commit events, or branch events, etc…and update the data in the process. The evil thought also crossed my mind of adding some SQL triggers to sqlite which check for undesirable commits or pushes and basically force an error which would theoretically rollback the transaction and prevent it from happening, albeit with an entirely un-useful error message. I know…evil… _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
