The main discussion at work some time ago was the definition of the versioning policy to be used. Being a large multi-layered service framework, which is going to be used by several external applications in the near future, it’s extremely important to clearly define version roadmaps and how new features and bug fixes will be included in each version: basically a full blown version control that goes beyond just saving all source files in a CVS-like repository.
One of the main obstacles I’ve found around here is the fear of creating a branch. Like those people who have an irrational fear of snakes or spiders, some developers seem to have a basic, almost primal, fear of branching in source control, although their previous tool (*cough*Visual SourceSafe*cough*) justifies such fear. The problem is not really towards the branch itself, but how things will work out later when changes must be merged into the main development: changes will be lost, builds will be broken, everything will go wrong, total chaos and things must solved by hand. It couldn’t be more wrong, modern version control systems, like Microsoft Team Foundation or Subversion, can handle automatic merging quite well, even allow selective changesets to be merged in the main branch and making the process much less painful than some people think it is.
Technorati Tags: version control, source control, cvs, subversion, team foundation, sourcesafe
Tags: source control, visual studio
