Version Control System with Flexible Sharing Mechanisms
Lasse Kliemann
in some version control system VCS for the various benefits that
come with this. Now I decide that a specific person P should gain
access to a specific file F, e.g. for proof-reading. I could send
the file to P by e-mail, P could send a changed or annotated
version back, and then I would incorporate the changes into my
working copy (and later do a commit). This tends to become a
tedious procedure if one has to do it often. It would be much
nicer to use the VCS for this, especially since the files are
already there!
Many VCSs allow access via SSH, and so one can use SSH public
keys for authenticating certain persons. However, this usually
means access to the *whole* repository.
Some VCSs offer more fine-grained configuration, specifying which
user is allowed to access which paths, and whether that may be
reading or writing. E.g., Subversion has the 'authz' feature, but
I feel the developers themselves don't like it much and I fear
that it might not be that well maintained. I was also wondering
whether there was something more "dynamic" available than that,
but could not yet find a way to describe that more precisely.
Which VCSs offer fine-grained access control? Has anyone had
similar thoughts like I had? Ideas?
Thank you!
Jorgen Grahn
> Suppose I work on a set of files, and as I always do, I put them
> in some version control system VCS for the various benefits that
> come with this. Now I decide that a specific person P should gain
> access to a specific file F, e.g. for proof-reading. I could send
> the file to P by e-mail, P could send a changed or annotated
> version back, and then I would incorporate the changes into my
> working copy (and later do a commit). This tends to become a
> tedious procedure if one has to do it often.
It can be more or less tedious ... you should probably have a sandbox,
or a branch, or use diff3(1) or something to make sure you can easily
review and commit his changes without risking to overwrite changes
*you* have done while waiting for the proof0-reading.
But it still gets tedious if you do this often, and in several
iterations. And it's a bit unfair to the reviewer to not offer the
VCS features you want yourself ...
So yeah, I see why you want to share the access.
> It would be much
> nicer to use the VCS for this, especially since the files are
> already there!
>
> Many VCSs allow access via SSH, and so one can use SSH public
> keys for authenticating certain persons. However, this usually
> means access to the *whole* repository.
And typically access to the whole machine, as a regular local user.
I'm not sure you can safely restrict a user account to just version
control.
> Some VCSs offer more fine-grained configuration, specifying which
> user is allowed to access which paths, and whether that may be
> reading or writing. E.g., Subversion has the 'authz' feature, but
> I feel the developers themselves don't like it much and I fear
> that it might not be that well maintained. I was also wondering
> whether there was something more "dynamic" available than that,
> but could not yet find a way to describe that more precisely.
>
> Which VCSs offer fine-grained access control? Has anyone had
> similar thoughts like I had? Ideas?
I think Unix people are suspicious of fine-grained access control in
general. I fall in that category and maybe the SVN developers do too.
- Does it really matter if the reviewer can access and modify the rest
of your data?
- Even if you ask him and he promises not to?
- Can you set aside your most private stuff, so you have only two
kinds: private to you, and open to everybody?
- If you had per-file and per-user control, would you be able to
control it? For example, I guess you would want to revoke access for
the reviewer after he's done.
I'm not saying noone needs control like that, but I suspect that many
people who *think* they do, don't.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
Kalle Olavi Niemitalo
> Some VCSs offer more fine-grained configuration, specifying which
> user is allowed to access which paths, and whether that may be
> reading or writing.
In Git, I think you can set up a pre-receive or update hook to
restrict which files a user can modify in a shared repository.
The hook would check the identity of the calling user, check
which files were modified in each commit that is being pushed,
and return an error if unauthorized changes were included.
The restricted user would still be able to modify other files and
commit those changes in her own clone of the repository, but she
wouldn't be able to get those commits into your repository.
In the Git sources, contrib/hooks/update-paranoid appears to be
a hook like that. I haven't used it myself.
Restricting read accesses in Git is more difficult, because Git
normally expects each repository to contain the entire history
and considers the repository corrupted if some files are missing.
You could however place the public files in a separate repository
and include that as a submodule in the main repository, but the
presence of a submodule would complicate things for all users.
Alternatively, a hook in the main repository could copy the
public files to a separate place whenever they are changed.