Hi Kristis, Yes, I guess that preventing commits to tags is really quite a small thing, and since there are plenty of things we want to do which do depend on the bug tracking integration, it doesn't really matter if there is one part that COULD be separated.
Is there a bug covering your suggestions regarding the access control based on the integration? I was thinking just yesterday how I would like to have a per-branch state, say one of: 1. allow all commits 2. only allow commits that specify a bug ID 3. only allow commits that specify one of a specific set of bug IDs (although I guess using keywords might be a better way of implementing this) 4. only allow commits from certain user IDs (which might not be the product manager or component owner - it might be someone that they have delegated to) 5. prevent all commits As usual, I wish I could contribute to the project, but I'm not the IT guy :( Regards, David ---------------------------------------------- David O'Shea Engineer DSpace Pty Ltd [EMAIL PROTECTED] www.dspace.com.au T: +61 8 8260 8118 > -----Original Message----- > From: Kristis Makris [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 18 September 2007 10:31 > To: David O'Shea > Cc: Marcel Loose; [email protected] > Subject: RE: [scmbug-users] Enhancement request: do not allow commit > toatag in Subversion > > > Hi David, > > I see where you are going with this. It feels more natural to separate > access control from integration. I doubt there would be any noticable > performance penalty. > > I can however think of some situations where "access control" may need > to rely on the integration. For example allow commits on a specific > branch only by the product manager or a component owner (both are > defined in the bug-tracker). Or commits should be accepted on a branch > only against bugs flagged by a specific keyword in the > bug-tracker (e.g. > ACCEPT_WHILE_FROZEN_FOR_3.0_RELEASE). Or only against bugs that have a > patch pending for review. The point is that setting read-only > tags is a > subset of setting up branches that accept limited patches going into > them (e.g. a released, stable branch that should only accept minor bug > fixes). > > The big argument you raise though is that implementation of access > control should not interfere with the ease of configuration > of the other > features of Scmbug. And I don't have a viewpoint or design of how this > could be implemented yet. This seems to be a much more > general problem: > most SCM systems don't support such fine-grained control of > access. And > to implement it, one needs to implement hooks and at least decode the > SCM systems arguments to those hooks. All of which Scmbug does. > > Perhaps you are just outlining the need for a more modular > architecture. > Were we should supply package scm-glue (which offers the > logic to decode > the hooks), and particular implementations of using those hooks from > there one (scm-glue-scmbug, scm-glue-DSpaceACL). I can't turn against > that. Perhaps people need the modularity of a common framework for > implementing on their own ... all the new features they keep > requesting > from Scmbug. > > The attitude so far had been to implement all in one framework only > because progress was relatively fast and no-one else was showing > interest in cooperating. > > Hmmmmm.... > > On Tue, 2007-09-18 at 09:04 +0930, David O'Shea wrote: > > Hi Kristis, Marcel, > > > > Just a thought on this: Here, we use a modified version of > commit-access-control.pl to make tags read-only. Would it be > better to concentrate on making scmbug very good at > integrating SCM and bug tracking and avoid adding features > that aren't tied in with that? If someone wanted read-only > tags but not SCM-bug tracking integration, would it not be > difficult for them to set scmbug up this way? If you had two > tools, scmbug plus something like commit-access-control.pl, > sure you would have the annoyance of having to tell two > different tools how your branches/tags/trunk in Subversion > are laid out, but that could probably be easily fixed by > making a common configuration file and with some > #include-style directive. Would there be significant > performance differences between using one hook and two hooks? > > > > Thanks in advance, > > David > > > > > > ---------------------------------------------- > > David O'Shea > > Engineer > > DSpace Pty Ltd > > > > [EMAIL PROTECTED] > > www.dspace.com.au > > T: +61 8 8260 8118 > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of > > > Kristis Makris > > > Sent: Friday, 14 September 2007 05:01 > > > To: Marcel Loose > > > Cc: [email protected] > > > Subject: Re: [scmbug-users] Enhancement request: do not allow > > > commit to > > > atag in Subversion > > > > > > > > > Hi Marcel, what you are proposing is not just possible > but would be an > > > ideal feature we'd like to add. This was proposed sometime ago: > > > > > > http://bugzilla.mkgnu.net/show_bug.cgi?id=859 > > > > > > No one is working on it right now. > > > > > > On Thu, 2007-09-13 at 13:29 +0200, Marcel Loose wrote: > > > > Hi, > > > > > > > > One of the "problems" I have with Subversion is that it > > > allows you to commit to a tag (CVS will not let you do this, > > > unless it is a branch tag of course). According to the > > > Subversion manual, you can make the tags directory > > > "create-only" by using an access control hook script. So, > > > since Scmbug is actually a, very nice and versatile, hook > > > script, would it be possible to add an option to Scmbug to > > > disallow commits to an existing directory in the tags directory? > > > > > > > > Regards, > > > > Marcel Loose. > > > > > > > > _______________________________________________ > > > > scmbug-users mailing list > > > > [email protected] > > > > http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users > > > > _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
