> The usual issue is making sure people outside the project are > prevented from reading the code. You might not want people in your > project making changes on tags and branches, but there usually isn't a > security issue if they see the code on the branches and tags.
Our issue is handling multiple companies doing development on the same project. Various restrictions (e.g. licensing) prevent us from sharing all project files with everyone involved. It's a tricky use case. We also have additional considerations which require us to control project read access within a project even within the same company. > The only way you can prevent people from reading your code is to setup > httpd configuration. pre-commit hooks can't do this and there's no > pre-checkout hook. Yeah, was afraid of that... > However, changing httpd configuration is tricky since it involves > having root access on the httpd server and being able to at least > bounce the server when the permissions get changed. Yes. Perhaps if there was a pre-checkout hook it'd be possible to create a homegrown admin tool. Or perhaps if Subversion had a feature to natively manage access control within a repository then no Apache changes would be needed in the first place. Either way, some automation would be useful here but it may not be possible to implement. > >> By the way, there's also a way to configure Apache httpd to use LDAP > >> instead of a regular text file. This means that users will have access > >> to your Subversion repository based upon their Windows or Unix account > >> and that users will automatically get logins and have their access > >> removed when they get hired or move on. > > > > That's something we'll definitely consider. We have some other quirks > > with account management to sort out first :) > > When your development team gets bigger than a dozen people, you start > having people come and go all the time. That makes it difficult to > keep the httpd configuration up to date. It just becomes easier if > this becomes more automated. Or at least someone else's problem when a > new developer doesn't have access to Subversion. I completely agree, and will be using that argument to push for it (or at least the first part :)
