views:

87

answers:

3

Hi everybody,

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!

+3  A: 

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.
Brian Agnew
Great answer, thanks Brian!
Industrial
Downvoted why ?
Brian Agnew
+5  A: 

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

unbeli
+2  A: 

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/.

repository layout

Matt von Rohr
Interesting drawing. Can you give me your opinion on why a DSCM is a better option for a small dev group compared to SVN?
Industrial
It's not that DSCMs are better than SVN for small dev groups **in general**, but from my experience setting up e.g. a Mecurial repository and starting to commit source code, sending patches to your collegues or exposing your repository is easier than setting up a central SVN server (which is what you probably would do when working with SVN).On the other hand the mentioned overhead becomes obsolete if you are using a hosting solution (bitbucket.com, github.com, assembla.org, ...). My advice would be: try diffrent solutions and see what best fits your needs.
Matt von Rohr
Mercurial definitely feels awesome! I set up a local repository and integrated it into my IDE and it's insane how natural the workflow was compared to SVN. Thanks a lot!
Industrial
Glad I could help! :)
Matt von Rohr