Good Version Control Guidelines from a Development/Collaboration Perspective?

Question

At our company we have started outsourcing some of our development.

This has worked somewhat well. However, we are having a hard time getting them to properly use version control. They are familiar with SVN and know how to use it. However, for some reason they don't commit regularly, instead they work with 16 things simultaneously and make a huge commits every 2 weeks, if we are lucky maybe with a few comments. Which makes it very difficult to both following and review their work, collaborate and also fix bugs. I have tried to explain to them to do their work as one small task at a time and regularly commit each of these with appropriate comments. Without much success, either they don't understand the concept or they are lazy.

My question is, what would be good guidelines describing how one should work with version control, not from a technical perspective (they know SVN), which seems to be the only thing I'm finding online, but from a development/collaboration/project perspective?

Answer 1

The firm is an outside company, so you can't really dictate that they follow a certain philosophy, workflow, etc. internally.

However, you have hired them, so what you can control is the requirements for what they produce. You don't need to convince them "this is a good process for programming"; all you need to say is "this is our company's process, and we expect what you deliver to conform to it".

Clearly outline your expectations, such as:

• The frequency of commits you require.
• Limitations on the number of changes in a single commit.
• The way changes must be documented.

You don't really have to justify why you want to do these things. However, it is likely that they will discover the benefit of these practices once they start using them.

Update I think Karl Bielefeldt makes some good points as well. Ultimately, it depends on what kind of role the outside developers are playing. There is a continuum: from contractors who work on site and are practically indistinguishable from employees, to an outside company that simply delivers a finished product to your specification.

Answer 2

In effect you are asking them to share unfinished work in progress with you, their customer. That's not very common in outsourcing arrangements, and comes off as micromanagement. Even if it's only partial outsourcing, like they are considered employees of your company, but are located in another country, remote sites usually have a lot of autonomy with work in progress. Also, some cultures are especially sensitive about presenting a good face.

On the other hand, smaller commits are easier to work with after the fact. You might have better luck with a different branching model. With a DVCS, the remote team can have their own private branch to commit all their work in progress, but they can choose not to merge that branch until the task is presentable, i.e. at the end of the iteration. You then get all the history, but they save face by not having to share incomplete work. I don't know if that's technically feasible with svn or not.