Re: [fossil-users] Restricting trunk checkins
On Tue, Feb 22, 2011 at 12:27 PM, Mike Meyer wrote: > 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. Doesn't lack of check-in permission also imply lack of push permission? Of course, that is a general permision. There doesn't seem to be per-branch permissions in Fossil. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Restricting trunk checkins
On Tue, 22 Feb 2011 07:09:14 +0200 Ron Aaron 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. 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
Re: [fossil-users] Restricting trunk checkins
On Tue, Feb 22, 2011 at 07:09:14AM +0200, Ron Aaron 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. > > Thoughts? As fossil keeps any history, users can do more than checkins, and they can do that in their own repository copies, I think this feature you want looks hard to achieve making all happy. If any user acts in a way you don't like, I think fossil makes you should have a personal conversation with him, and you will have to restore the trunk state from history. But maybe someone has a different view, and comes with a great idea to solve the situation with technical means. :) Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Restricting trunk checkins
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? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
