On 5/11/2015 11:39 AM, Andy Goth wrote: > On 5/11/2015 11:29 AM, Ron W wrote: >> If the project is too big for re-cloning every time there is an >> accidental commit to trunk, then you could require the contributing devs >> to send "bundles" to the integrator. On import, commits from a bundle >> have a special status that allows them to be un-imported. > > This sounds like it could be automated. But whenever something that may > be a commonly desired feature can be automated, it ought to be > considered for integration (functionally speaking) into Fossil itself. > > In other words, this is something I've wanted too. :^)
Actually I should expand on my desire a bit. My wishlist derives from my organization's needs which are currently being met by ClearCase and many trigger scripts piled on top. When I say "restrict" below I don't necessarily mean that the facility be limited to only an administrator or superuser, but that other designated users or groups be able to do these tasks, and not on a blanket basis but rather in a configurable way, e.g. X group manages Y branch. Right now there's a lot of stuff at work that have to be done through admin requests, and they can take days to process. - Restrict commits and other such changes to not only trunk but other branches as well - Restrict the naming convention of branches - Restrict the naming convention of non-propagating tags - Restrict control cards, maybe just bgcolor, maybe others - Restrict editing of old commits Of course this is far too much to ask to directly build into Fossil, but that doesn't mean Fossil's scripting mechanism can't be extended to the point where it can enforce this policy. -- Andy Goth | <andrew.m.goth/at/gmail/dot/com>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
