Using SVN alone or in small workgroups - workflow approach?

Question

I have spent some months working on a web application and we're come close to production stage. It's soon time to expand the development group with 1-3 people on this project.

I have not too much experience on working with SVN, but It's obviously the choice for a big part of the larger companies out there, so I am guessing that the pros of SVN without a doubt outweights the time spent on commit/check ins / check outs etc.

The workflow seems to become a bit more complicated with SVN, and even though I have read Version Control with Subversion by O'Reilly Media and I am not sure yet if it's overkill to use SVN for any reasons besides backup when developing alone or in a small (1-3 people) workgroup?

How do you do it? What's your workflow with version control while working alone or in small workgroups?

Thanks!

Answer 1

Like any SCM, it's definitely for more than backup.

1. You can tag particular releases, so you can identify a point across all of your code that makes up a release.
2. You can manage branches for different simultaneous releases e.g. if you need to manage bug fixes for a release whilst developing a new version of your solution.
3. You can manage multiple developers and use SVN's merge capability to handle concurrent changes, such that your developers don't tread on each others toes and overwrite or erase each others' changes.

I don't develop on my own without an SCM, let alone together with other developers. It's a core tool in your toolbox and worth getting au fait with sooner than later.

What's my workflow ? It depends on the team and the SCM being used.

1. If the SCM supports it well (e.g. Git), I'll create a branch per bug/feature. SVN is not so hot at branching, so this may not apply.
2. I check in/merge regularly. If you don't do this often, the codebase will diverge from your working codebase, and a subsequent merge will become more difficult. Additionally, you want your team members to have visibility of what you're doing.
3. My continuous integration process (e.g. I use a continuous build engine such as TeamCity/Cruisecontrol/Hudosn) will build/test and optionally tag a release upon a successful build/test cycle.
4. I'll create a branch for a final release, and will work off this for maintenance following release.

Answer 2

No, it's not overkill. Version control is vital for programming, regardless if it's alone, in a small or in a big team. It removes fear of doing a "wrong" change, as you can always go back to previous revision. It remembers why a change was done with commit messages. It knows what was changed together. And many more

Answer 3

There's not much to add to Brian's answer. As an alternative you might want to take a look at distributed source control systems (DSCM) like Mercurial, Git or Bazaar. IMHO they are a perfect match for small developer groups, very easy to setup but nevertheless manage to scale to big projects.

A good introductory tutorial about Mercurial, written by Joel Spolsky, can be found at http://hginit.com/.

_{(source: hginit.com)}