3

I have currently collected a large part of my work under a single and nicely organized repository in subversion.
When another person, say X, needs to collaborate on a sub-project, say /path/to/my/subproject, I can simply give X permissions to read/write in that specific path.
From my point of view, I still have the nicely structured repository and doesn't need to do anything else than modify some simple permissions for everything to work for X - and from X's point of view, he has just access to the relevant part. Everybody is happy.

In a distributed VCS like git or Mercurial however, all access seems to be given per repository.
I therefore fail to see how to obtain similar functionality as described above in these systems. It seems that I have to create a whole new repository if person X suddenly needs access to parts of my original repository.
Furthermore, if another person, say Y, needs other access rights within the path that X has access to, I have a problem.

Can I obtain similar functionality with differentiated access rights in distributed VCS's as I currently have in subversion? If so, how?

someName
  • 1,275
  • 2
  • 14
  • 33

2 Answers2

2

One other option is to add an authorization layer like Gitolite.

It has settings for authorizing a user to:

But more generaly, yes, one project often equates one repo, in order for that "component" ("coherent set of files") to evolves on its own, independently of others.
You can then join those repos within one parent repo through submodules.

The lack of authentication and authorization is explained in "Distributed Version Control Systems and the Enterprise - a Good mix?".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

This is not possible in git, or any other DVCS that I know of. The idea of a DVCS is to decentralize everything. This carries with it the fact that the repository has no central authentication. If joe clones your repo, he has full access to that entire repo. Now you can limit what you pull into your repository, but he can do anything he wishes with his.

There are 3rd party solutions like Gitolite that would allow you to get close to the behavior you wish, but it would require that you setup a server and track keys. Which may be worth it

The key thing is that, as far as I know, there is no way to limit read access to a sub directory of a repository. Write can be taken care of in Gitolite or by selectively doing your git fetch, but once a user has cloned a git repository, they have full control of the entire repository while it is on their machine.

From the Gitolite manual:

  • Read access controlled at the repo level
  • write access controlled at the branch/tag/file/directory level, including who can rewind, create, and delete branches/tags
Andy
  • 44,610
  • 13
  • 70
  • 69