Managing GIT permissions - multiple repositories

Question

We have several development teams, each of which develop multiple projects (10+ usually). We are currently in CVS and evaluating whether to move to SVN or GIT. I am leaning towards GIT, however I am not sure how we can manage the permissions efficiently. For example.

We have Dev Team A, Dev Team B, Dev Team C. Each of which have 12 developers. Each Dev Team has at least 10 separate projects. Team A can see everyone's code, Team B and C can only see their code. Additionally some developers only have Read Only access while others have Full access.

So in CVS we have three repositories, one for each team. So it's like:

/cvsroot/TeamARepos/project1
/cvsroot/TeamARepos/project2

/cvsroot/TeamBRepos/project1
/cvsroot/TeamBRepos/project2 

/cvsroot/TeamCRepos/project1
/cvsroot/TeamCRepos/project2 

and so on. I can manage the whole repository and say John Doe has read only access to A but write access to B and no access to C - and therefore I don't have to give him explicit access to each project (and they get added pretty frequently, so I don't have to add everyone to every new project each time).

My understanding of GIT is that I would have one repository per project. So there isn't a real logical way to say 'all of Team A's code is here and these users can write to it' and 'all of Team B's code is here and these users can read it' and keep it separated like that.

I'm not sure I even know how to ask the question right - but I envision moving to GIT as an administrative nightmare.

We also use ant scripts to check code out of CVS, do the builds, and deploy to the servers. I have just started to look but I'm hoping ant plays well with GIT in that sense too.

Answer 1

I suggest using git over svn because of its speed, distributed version control model, and overall sane way of doing things. We were using SVN at work for a few years, and it was a real pain compared to git. The only advantage I saw with SVN was its integration to Windows with e.g. TortoiseSVN. But that's only if you like to be constrained by the GUI, and are not willing to learn the much more powerful command line.

With git you clearly need gitolite to handle the access control. With this model you set up a different repository for each project. Gitolite configuration file allows you to group developers into teams, and then you can set up very fine grained access control per repository, branch, or even working tree path. You can specify the permissions in terms of teams, or individual persons, whichever way suits you best.

If you need code review, you should also check if gerrit is the right tool for you. You don't need both, use either gitolite or gerrit.

Sometimes people find git hard to learn. For that, I suggest to point the developers to a good book, for example this. It's also available in print.

Answer 2

Subversion may be a more smooth way for you (at least in the migration and administration area later).

"Merge Hell" is a much hyped myth and bogey from the side of Git-boys and lazy unqualified SVN-users. Well, it really exist under some condition ( in form of "Refactoring Hell" for teams of any quality), you just have to detect, does this condition applicable to your workflow.

You said nothing about existing server OS and infrastructure in common, it some cases it matters. Git server and some frontend under Win is real nightmare and horror, f.e, for Linux-side I can't find such compact and usable solution for Subversion over http, as VisualSVN Server (Enterprise Edition) for Windows (UberSVN is overbloated from my POV). If you have Java on server, you can think (for the sizes of your teams and amount of repos) about SCM-manager (for any selected SCM - it supports Git, SVN, Hg from a box)

Answer 3

If you want to see code from all of team A on multiple projects, you can make a catch-all repo that has remotes to all the repos and just git fetch --all, then do your analysis.

Gitolite makes administration (down to custom hooks) a breeze. It gives you control of who can read or write down to the branches. You can even implement your own git hooks to put in other custom safety measures such as ensuring everyone includes a ticket reference in each commit message. I've been using it for the past 2+ years and it's wonderful.

We moved from SVN to Git because of the conflict resolution pain, speed and many other reasons one of which was the adoption rate of git. Storing resolutions in rerere allows easy mixing and matching of features. Hooks are easy to write and we can enforce OCP on certain repos that contain code contracts. All this was very cumbersome in SVN - if not impossible.

As per the CI process, git works well from the command line so you can do what you like in any automated build tool. Support comes out of the box for all major tooling of this sort now.

This is the process we follow in each of the repositories with git: http://dymitruk.com/blog/2012/02/05/branch-per-feature/