[thelist] Getting version control into the office for the first time

[Ken Snyder]

Barry Woolgar wrote:
> Hello all
>
> I'm hoping to convince the boss about the benefits of using a version
> control system over the current system of there being _no system_. We are
> taking on a third developer soon and I can see things going quite wrong
> quite quickly. 
>
> I've read up about Subversion and it seems the way to go, but I'm open to
> suggestions of simpler alternatives if you have them. 
>
> So, my questions are:
>
> What are your experiences of getting version control into a development
> environment (we are a LAMP house) for the first time? 
>
> What things do you wish you'd know about before you started (technical or
> otherwise)? 
>
> What would we need to look out for with regard to common mistakes and doing
> things the wrong way (ie, bad habits)?
>
>
> I'd appreciate any comments, suggestions or warnings you can share -
> unfortunately there's only so much I can learn from developing with a local
> repository and myself.
>
>
>
> Thanks in advance, have a good weekend
>
> Barry
>   
I think Subversion is great for beginners.  Git and other decentralized 
versioning systems have a pretty steep learning curve in my opinion. And 
they are arguably no better than Subversion for a small or medium sized 
development team. (Feel free to disagree but don't flame me, I'm not an 
expert!)

But the hardest part about moving to versioning is not the software, but 
the integration with your current development and deploy processes.

My company used Source Safe with PHP until last year. It was pretty 
tricky getting everyone familiar with Subversion, but we are still 
having trouble nailing down a good strategy for branching and reliably 
merging several projects (from 7 developers) that are deployed together.

Our C++ team has been using Subversion for years, but it is a lot easier 
with compartmentalized binary distribution.

With applications with a lot of interdependent files like PHP, 
versioning gets tricky. I'd recommend reading a lot on development and 
deplolyment strategies (e.g. agile, broken trunk working branches, 
broken branches working trunk, deploying through updates, deploying 
through patches, automated deploys, when to branch, etc.)  I'm no 
expert, but I can say that there are a lot of potential pitfalls.

The best thing we've found is to study up on versioning, try out 
different strategies, and move slowly.

My 2 cents.

- Ken Snyder