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