2009-11-13

directory level access control via gitolite

I'd like comments on this from my readers.  Don't worry if you don't know what git is.

All you need to know about git/gitolite to understand this post and comment is: (1) git is a modern version control system for source code, (2) git makes using branches (different development lines for the same project; like "release", "maint", "customer-specific", etc) almost trivial, and (3) gitolite is an access control layer that sits underneath it and implements restrictions based on branch name (ie., only the QA guy can push to the "QA-done" branch).

The question was: we need "path-level" restrictions also (I can only change files in subdirectory-A, you can only change files in subdirectory-B, etc).

Here's the email I sent the person who asked me for this feature, and on which I want your comments.

----------

I have a small philosophical objection to this sort of restriction.  Let me explain.

I want the computer to catch mistakes that are easy to make, and hard to reverse.  Pushing the wrong branch is a good example (esp if some branches have similar names), so gitolite is focused on branch permissions.

Touching a file in another directory is a mistake that is hard to make and easy to detect and stop.

Normal workflow is that devs only push to their own branches, from where their code is picked up for QA and (if accepted) moved to the main branch by someone with that authority.  If QA can't even detect that the wrong files have been touched, you have a bigger problem than gitolite can solve :(

Automating subdirectory based restrictions seems as if you are using gitolite as a substitute for internal team communications.  And maybe even trust.

1 comment:

Radha said...

I agree with your philosophy. But I agree with him/her too - sorta. At least I can understand what s/he is trying to cover.

Think a large dev team working on a total of 200 programs. I would want a 'tech lead' to assume responsibility of knowing what is the 'final' dev version, ready to be pushed to QA, maybe after the tech-lead does a personal testing.

The junior programmer could (should) have a work directory, but when she thinks a progam is ready (she's done with her level of testing), she should submit/push it to the tech-lead's directory. Once done, she cannot access that program in that directory, only the tech-lead should have access to it. If she suddenly remembers the if-clause she forgot to put in, she will need to do the push again, which becomes the next version-lette in the tech-lead's directory.

This will help isolate the programs at each level of responsibility and help reduce the potential for bigger mess.

I think this request is just finegraining gitlite's existing functionality : just as you assumed an organization is made up of different 'branches', you have to accept that each branch will need further subdividing for complex organizations. To the extent till you end up at the lone individual at the 'leaf'.

Bottomline - I see gitolite is gaining fame, which means that you will see more of these requests! You might as well think ahead...


Btw - I am following you on gitolite closely, but am frustrated that I cannot use it in my job and environment.