I really like the idea of being able to set which people have write access to a project. I am wondering if we have be able to restrict access a more within a project.

Eg: I have someone who is very knowlegable with shipping, would like to let then access just the shipping module within ecommerce, and then they cannot break any other areas.

If would be nice if you could use a regex to detemine which files they have access, so in the case above I would add something like "shipping/.*|contrib\/shipcalc/.*"

Also it would be nice if I could have contributes commit access to just a branch of EC, like assign someone to be the maintainer of the 4.7 Branch. An idea for this would be to have just a tag select menu which says all, and a list of all the branches. If they have access to multiple branches they will occur multiple times in the list.

Comments

dww’s picture

dww
we/he/they
commented
Project: Project » CVS integration
Version: 5.x-1.x-dev » 6.x-1.x-dev
Component: Releases » X-CVS scripts

+1 on per-branch.

i'm less thrilled about per-directory. i've written numerous times about the woes that come from having "subprojects", so i won't repeat myself here. basically, if they're really separate, stand-alone chunks, they should be in their own directories with their own project node, their own tagging, packaging, access control, etc.

but, we don't currently have a nice way to group project nodes themselves, show inter-project dependencies, or generate "distributions" with specific (or "latest") versions of a collection of related modules. until we have those things, it'd be more of a pain for users of EC to deal with 30 different downloads, so i'm sympathetic to your request.

however, for now, i'd say you have to appeal to sanity and trust: if you trust them enough to not screw-up the shipping code, you should be able to trust them enough to follow your instructions "please don't commit anywhere else"... i know it's not ideal, but it works for core (e.g. killes has acess to commit anywhere, but by convention and trust only commits to DRUPAL-4-7).

that said, i'm not setting to "won't fix", which should hopefully be encouraging. ;)

cheers,
-derek

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

Here's my situation for consideration. I've just created an add-on module for the FAQ module. Since mine is totally useless without the other, it seems silly to create a whole new CVS set-up. It would be better for me to contribute it to FAQ to be distributed with that. However, whether the FAQ owner is willing to grant me CVS access is immaterial - I don't want the responsibility or risk.

I'd like my stuff to be part of the FAQ distribution (similar to Views contribs), but I guess that's not in the cards?

stella’s picture

stella commented

+1 for this feature

jpetso’s picture

jpetso commented

Just noting that the Version Control API / CVS backend combination (using xcvs-*) provides a write access hook that can be implemented by custom extension modules too. So even if it doesn't go into the main set of modules, per-user restrictions could pretty easily be coded as optional add-on. Not that this solves anything for cvs.module itself :P