Question

Using SVN or Git the thought had occurred to me to use the directory structure as a meta data place holder. Each team would have a directory in a shared repository for their code. The more I think about it though the worse the idea seems. The reason it appears like a bad idea to me is that teams are not static entities. Teams can vanish, split up, recombine, and even get a new name. I know I am looking at using a unique identifier and probably an external database. I am probably even facing a per team repository to manage access rights appropriately. In a situation with 200 or more teams, am I best off maintaining ownership in an external database or are there some tools and practices I could learn from?

Answer 1

Here’s my best attempt at pointing you in the right directions. Generally speaking:

Organize your source code according to the components of your system in the usual way. Make sure that each component can have access control configured independently (e.g. in git, this means separate repositories for each component, as Makis said).

Managing access rights is commonly done in conjunction with LDAP these days. Configure your tool to leverage your organization’s LDAP directory in the usual way. (for git, this is more commonly done using the existing accounts on the system, which may or may not be backed by LDAP).

Use your version control system’s built-in access control mechanisms in the usual way to allow each team to read or write to each component as appropriate. If this matrix of permissions becomes too cumbersome to manage manually, build a custom mechanism to control it at a higher level and/or automate large-scale updates.

If you don’t have a component architecture, centralized user accounts, or access control for your VCS, then give up on this problem until you fix the more important ones.