Managing Contractors with SVN on Projects

Question

What do you recommend for using SVN as a means to manage development of a project using remote/external developers in terms of code review/managing changes,etc? Should everyone checkin to the trunk and provide comments for everything or do people use patches, branches, or some othe process to manage this? Please provide any suggestions you have for having a small team of remote developers (5) submitting work into SVN and a single individual overall responsible for the project's development who reviews code changes, etc. Thanks

Answer 1

It depends on the specifics of the project. Is it a team assembled to complete a project and be gone, or is it an ongoing effort with versions. release schedule, etc.

We are closer to the latter. Here is our process:

• For a new release/feature of a considerable size we create a separate branch.
• The developers can check in the code - we push for every checkin to have a comment.
• To stay in synch with the trunk the branch owner is responsible for merging trunk into his branch
• When the feature/release is completed the branch is code-reviewed and merged back into trunk
• the branch is deleted. If the work on the branch has to continue the branch has to be re-created - this due to SVN limitations

Edit

To elaborate a little:

The branches are the playground for ongoing development. Every developer (or developer lead for bigger features) is responsible for his own branch, including proper checkin procedures (checkin comments) as well as synchronzing with the trunk.

The trunk, on the other hand is a place of stability - at any moment you should be able to build a working version of the app off the trunk. As a matter of fact we have a CI process doing it automatically with every checkin.

To achieve this stability the changes are never made directly to the trunk (except for smth really small and really urgent).

The process of trunk modification is a responsibility of the internal developer. Once the owner of a branch declared it ready for production, the internal developer has to review the submitted code (from the branch) and merge it back into trunk.

After the merge back the branch becomes unusable and has to be deleted.

Answer 2

The answer to this will depend on:

• How much do you trust the contractors?
• How much effort does your group want to put into managing this?

Here are some scenarios:

No Trust

• Read only repository access
• No access to trunk
• Submissions are done with patches
• Somebody on your team will manage the patches

Medium Trust

• Read-write milestone branches
• Contractors submit to milestone branches.
• Somebody on your team merges into the release branch

Full Trust

• Full access to trunk
• Contractors in charge of merging their changes

As for best practices, I suggest the following:

• Track milestones with burn-down chart, or the system of your choice
• Make everybody commit with comments (could use a Subversion hook for this)
• Align code commits to a specific item/ticket in a management system like FogBugz, OnTime, ect.
• Large features or milestones should have their own branch. Merge to trunk one the feature/milestone has been validated by somebody on your team.

There are just some ideas. You'll have to find what's best for your mix of team members and contractors.