If you have been programming for long enough you have probably had situations where your svn solution made you very angry. Last week I had one of those moments, and so, considering the hugeness of the pitfall that I found myself in, once again had to go over the benefit I have had from the SVN solution, so that I could feel better about negotiating for extra time.
So – here are the reasons I love my SVN solution (to try to explain why we still don’t go without it, even though a few horror stories might have convinced us otherwise):
I can work on a task (for example adding functionality to a page) and commit my working code which automatically gets included in a project build. The build runs with (not only my own work), and the online solution gets updated with the said functionality, and perhaps other functionality – even to the same page – so that the cutover between the older solution and the new one is seamless.
Project contributions can be made by developers from anywhere that there is an internet connection. All the solution’s code in one central place…
And now, to explain the problem we had:
There is a working solution that is fully operational in the LIVE environment. It is the day of your deadline. You commit your working code, and suddenly the live solution is no longer operational. What happened? Somewhere between committing your code and deployment, something went wrong. And now, the search for the problem begins, and, a week later, version 2.0 is finally live.
A week lost: who is to blame? The developer? The team lead (who is normally also in charge of the project builds on SVN)? Bad up front planning? Training for employees (version management)? Because once the developer signs in that working code, are they no longer responsible? A team works together. When developers on a team help each other and stop blaming each other this always contributes to a successful project.
And with this I sign off, with another module of code successfully added to another fully functional solution.