On Tue, 22 Feb 2011 07:09:14 +0200 Ron Aaron <r...@ronware.org> wrote:
> One feature "missing" from Fossil is a way to restrict checkins on the > 'trunk' > (or other branch) to certain people. > > This is necessary in a group where the methodology is for a "gatekeeper" to > approve integration into the main line of development. > > Has there been any thought along those lines? In my perfect scenario, a > branch (including trunk) may have an ACL list which would restrict who could > do what operations on it. > > The way I envision it working is that if a branch has an ACL, it would get > checked against the current user and kind of access, which would be approved > accordingly. > > In current practice, I have two repositories, one with "golden" code and > another to which any developer can contribute. This is a little bit painful, > as you can imagine. > > Thoughts? First, you can't really restrict just checkins on the trunk in a DVCS. Someone can always make a personal clone, unset whatever you have that is preventing those checkins, and then checkin on the clone. So you have to restrict pushes to the trunk as well. Because of that this feature seems to be missing from most DVCS's as a feature per se, but is covered by another common VCS feature that is missing from fossil: hooks. This kind of thing is then done by a pre-commit and pre-receive hook with the ability to reject the change. Hooks are apparently "in the works" for fossil: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg03190.html If your developers are only pushing changes into the repository (i.e. - no direct commits) and it's being run under an HTTP server, you might be able to get the servers authentication system to help here. I haven't looked at what fossil is actually doing under the covers, so this may not be possible at all. Finally, I think you've already found the correct solution with two repositories. Yeah, having to deal with two repos is a little bit painful - but it's only a *little* bit painful. Instead of merging from another branch, you have to pull from another repo. If you've got both repos being served via an http server (and here the server auth system should be able to help - you should be able to restrict access to each repo individually), that should be the only difference. <mike -- Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
