El 17 sept. 2017 2:01, "Ron W" <ronw.m...@gmail.com> escribió:
On Sat, Sep 16, 2017 at 8:00 AM, <fossil-users-requ...@lists.fossil-scm.org> wrote: > Date: Sat, 16 Sep 2017 01:15:25 +0200 > From: Johan Kuuse <jo...@kuu.se> > Subject: Re: [fossil-users] Shameless self-promotion > > > >El 16 sept. 2017 0:39, "Warren Young" <war...@etr-usa.com> escribió: > >>> On Sep 14, 2017, at 11:12 PM, Johan Kuuse <jo...@kuu.se> wrote: > >>> > >>> A commit pre-hook running an automatic indenting would have solved this > >>> problem. > >> > >> Coding style is a social norm. It should be enforced by social means, > not > >> technical means. > > > > Must disagree here, at least when we are talker about bigger communities, > > where some kind of technical control/help is necessary to create some > kind > > of "community standard". > While I work, we include a step to run QAC to perform source code analysis and style checks in the build rule for compiling a source file, so each source is validated before it's even compiled. Sorry for my ignorance, but I have never heard of this tool. Do you refer to https://en.m.wikipedia.org/wiki/QA-C ? If we wanted to auto-format the source code, we would add a step before QAC. That way, it would be the (re-) formatted code that is validated and compiled. Then, once the build successfully completes, source changes are automatically committed in Fossil. Sometimes, we will do "manual" commits between builds, but our build process insures that what actually got built is also committed. At work, we use the follwing workflow and tools: Pre-hooks to check the commit message, which must either start with WP (Work Package, i.e "feature"), or TR (Trouble Report, i.e. "bug fix"), followed by a unique ID for that feature/bug fix. (For rare cases, the commit message may also start with OTHER.) No source code formatting takes place with the pre-hook, but it has been proposed. The commit is first sent to Gerrit, used as a "Git proxy". The commit triggers a build, handled by Jenkins, which compiles the code and runs all test suites. My colleagues may analyze my new commit (manually, a.k.a "code review") using Gerrit, and either reject or accept my commit. If either the Jenkins build fails, or at least one of my colleagues reject my commit, I commit --amend a new patch, which triggers a new Jenkins build and sends a new email to my colleagues/code reviewers, and so on, until both Jenkins and my colleagues accept my new code. I may then submit my new commit to the "real repos" (i.e. "trunk", a.k.a. "master" in the Git world). Gerrit is a user-friendly tool, but its function could obviously be substituted with a new branch in the same repos as trunk. The new branch would have the same function as a "proxy", before merging the commit into trunk. What I do think are nice features in this workflow are the hooks, where the pre-hook watches my commit message syntax, and the post-hook triggers a code rebuild, and also sends a mail to my code reviewers. Is anyone here on the list using Fossil with similar hooks? Or combining Fossil with other tools to achieve the same? BR, Johan _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
