On Sun, 21 Jul 2013 21:15:56 +0200 Stephan Beal <sgb...@googlemail.com> wrote: > > a) when a user sync/merge to trunk in central server, it compile/test > > the code, after receive but before merge, and if compile/test fails reject > > sync/merge. > > b) project management features, global gant graphs, percentage of work > > done, > > c) source code parser, to find where a function, macro, etc... is > > declared > > d) fts of documentation > > > > If we don't want to write such hooks in C (which might not be practical) > then a a scripting engine is implied. IMO the right choice, given fossil's > history, would be TCL, but any option we choose brings with it long-term > dependencies or maintenance (if we embed a small interpreter like jimtcl or > lua). To me jimtcl would be the obvious candidate, but i was told at some > point that it has too many incompatibilities with standard TCL to be of > interest to the harder-code TCLers.
No, not as hooks, but as plugins. I think that include a scripting engine is great, I'm a lua user, but force to use only one not. Allowing to call external have this advantages: a) Not tied to one scripting language b) In smp environments, the script will run on other processor (or even remotely) c) It can work asyncronous, fossil may not wait the script ends d) If script fails, fossil will not hang or crash or silently quit e) Fossil size keeps tiny f) Scripts can be persistent g) Update/Bug fix script engine without recompile fossil or wait for a new fossil release Of course, with security at first. About hooks, thinking more about it, perhaps something more like a trigger. For example, in our c projects, we have this on the central repositories: 1) a user syncs to central 2) after sync, we must run a script manually that 3) checkout last trunk version 4) compare trunk with trunk 5) if some change is detected, compile with clang static analyzer, it has an option to make an html report 6) add the report directory to reports branch 7) copy the new trunk to old trunk dir and rm everything else 8) close the checkout It will be great if fossil shoots the script each time trunk is modified, > > d) extend user capabilities > > > > Some superuser can own/lock some files in central repository or at > > least, in trunk. For example makefiles, binary files, project > > configuration, etc... > > > > i was thinking about that as well, but IMO the current system works > remarkably well. It effectively offers up to 26 (or 52) roles, which is far > more than projects of fossil's scale need. We could perhaps add a mechanism > to allow clients to add letters to the permissions alphabet. Or toss out > the mechanism and do something new. i think a full-fledged role management > system would be way overkill, but if we're starting from scratch anyway... Perhaps I mixed the concept of user and role. I thought more about the concept of file owner. By default all users owns all files, but some roles, like superuser or project architect, own some files or dirs and only him/her/it can modify them. --- --- Eduardo Morras <emorr...@yahoo.es> _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
