A solid version control tool for a wide range of software projects
September 14, 2017
A solid version control tool for a wide range of software projects
Score 9 out of 10
Vetted Review
Verified User
Overall Satisfaction with Apache Subversion
We used Subversion to manage a ColdFusion based software development project for a US Federal government contract. We were largely isolated (both geographically and organizationally) from the rest of the company (it was their attempt to get into Federal contracting) and I'm not sure what was used in other parts.
Our biggest reason for using it was to allow working on multiple releases in parallel. Before I helped set up Subversion properly, they were delivering old code with new releases, "clobbering", as they said, previously delivered code. By setting up proper branching, I fixed the problem, to the relief of both the company and the customer.
I also integrated it with the Redmine issue tracking system, requiring developers to associate issues with their commits.
Our biggest reason for using it was to allow working on multiple releases in parallel. Before I helped set up Subversion properly, they were delivering old code with new releases, "clobbering", as they said, previously delivered code. By setting up proper branching, I fixed the problem, to the relief of both the company and the customer.
I also integrated it with the Redmine issue tracking system, requiring developers to associate issues with their commits.
- Version control - it's what it's designed for.
- Modifiable - It only takes a little bit of knowledge of a scripting language (I used Windows BAT files calling Perl scripts) to extend capabilities, like the aforementioned integration with Redmine.
- Back end administration- It's a breeze. There's very little work involved in terms of administering it once you've got it installed on a server, and even setting that up isn't bad.
- Distributed development - I've never worked in an environment where distributed development (developers widely scattered geographically) was a factor, but that's why Git exists.
- Merging - Merging of code from one branch to another can be painful, especially if it's not done frequently. (On the other hand, doing merges is one of the reasons I get a nice salary, so I can't complain too much!)
- It allowed us to deliver the right files to our customer without "clobbering" previous releases, making for a far more satisfied customer.
- It allowed our developers to work on two releases in parallel (plus an occasional third, for emergency fixes).
- With some simple hooks, it allowed us to set up a system where code was was automatically deployed to test servers as soon as developers committed it, making testing easier. This was made easier by virtue of being a ColdFusion project, which requires no compilation. However, that is possible for compiled code with a continuous integration system like Jenkins.
Git is probably the biggest open source rival to Subversion. It's designed for distributed development, an environment I'm not very familiar with. I've only got some experience with it, and only as a user, and even that is limited. I had some trouble wrapping my mind around the model, until I had a moment like a cartoon light bulb going on over my head when I realize "every developer has a private branch!" That's not 100% accurate but it's a nice way to look at it. It also doesn't require (but still can use) a centralized server, which can be nice for small projects. It's my understanding merging is much easier.
I have no experience with Mercurial but I understand it's very similar to Git.
ClearCase is a bloated mess, difficult to use and administer. It's also VERY expensive. I'd only even consider it for a massive enterprise level project.
I have no experience with Mercurial but I understand it's very similar to Git.
ClearCase is a bloated mess, difficult to use and administer. It's also VERY expensive. I'd only even consider it for a massive enterprise level project.