Subversion with contract development team

Question

Any suggestions on best practices for providing access to subversion to a 3rd party development team. We've hired the team to work on a small iteration of the project and I don't want to give them access to the whole respository. We use BeanStalk to host our subversion so granular access control down to just a branch isn't possible (I don't know if beanstalk is the limit here or svn in general).

Instead of creating a branch in my main repository I created a new repository and gave them access to that with only the most recent snapshot of code that they'll need. I figure I'll have to merge their changes manually either way.

What would you have done?

Answer 1

Frankly I don't know much about SVN server set-up. Our SVN server -- "Collabnet" is part of the name, that's about as much as I know -- allows us to put users into groups and then to assign permissions to each group at any level of granularity.

Given that, we have some off-shore developers whom we orginally gave their own directory under "branches", had them do their commits there, and then merged these into trunk.

That proved to create unnecessary merge problems though, so we've now switched to just having them commit to trunk. We can see the user id on the commit in the logs so we know who committed what.

In general, my philosophy is that if you don't trust the code your developers are writing -- whether they are in-house, contractors, or whatever -- you should get different developers, not search for ways to slow down the harm from their bad code. Sooner or later you're going to have to merge in their code, so what's gained from delaying this?

Answer 2

I probably would have started a project on Google Code and done the same thing, merge the changes in later when they were done.

Or if your software is componentized, create a separate project altogether for each independent component then you do have access to give them just what they need to do their job.

Answer 3

I think I'd dumped an existing repository, then loaded relevan pieces into a new one and then gave access to that new repository to a third-party team, so they would have an existing codebase to start working on. The ultimate reason I'd gone to such lengths is that in this scenario I'd be able to generate a more or less sensible diff, so that manual merging would not be such a daunting task.

Answer 4

A nice solution is available - check this answer. However, it may be that you are not able to do that since you are using an external provider.

Answer 5

I don't intend to be flip, but I would want an SVN host that allowed me to use fine grained access controls in my repository.

That aside, I would have also explored using svn:externals to connect the repository handed off to the outsourced team and my main repository. A clever set up might mitigate some of the merging effort.