On Mon, Jul 22, 2013 at 12:09 PM, Eduardo Morras <emorr...@yahoo.es> wrote:
> ...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 > For some checks Fossil _must_ wait on the script to end. How can it do a commit confirmation check if it doesn't wait on the results? > Of course, with security at first. > One of my weak points - i'm very much relying on others to spot any potential security problems. > 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: > To be clear, i often use the words hook/plugin/trigger interchangeably. > 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, > Ideally we'll be able to do that type of thing. We need to define (A) when various hook points will be triggered, (B) what parameters/data they receive from fossil, (C) how fossil should deal with various exit/result codes. e.g. do we just have success/failure, or are there varying degrees of success/failure? This topic will certainly keep us busy for a while (but will be very interesting). Once we are far enough along to have a script binding of some kind we can experiment with this freely before deciding on concrete semantics. > 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. > i think that would be impossible to implement properly in a DVCS (it would be possible in a centralized SCM). When i clone your repo, i need access to ALL of the files i cloned. If i cannot check out or modify certain files just because you "own" them, the repo is useless to me. It means that if a developer dies (as they occasionally do) then all of his locks are there forever. This doesn't sound realistic to me. One of the things fossil promises which other SCMs do not is "forever" - it's data format is designed to outlive the software, which means that in 200 years someone could read the fossil data format, import an ancient sqlite3 fossil DB into his sqlite27 db, and get back to work. Except that now he can't make changes because the files in the repo belong to another user ;). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
