Is Version Control necessary for a small development group (1-2 programmers)?
I am trying to debate the point that version control is important for either one or two developers.
More specifically, I work in a department in which there are typically two PHP developers, using a shared framework. He argues that there is no value added in us having Subversion installed on our development system, whereas I argue that it is nice to occasionally be able to roll back to see previous code, especially when there are unexplainable errors occurring that are hard to pin-point in some of the classes.
I think Subversion offers the easiest way to create and track changes, for various reasons, including debugging. Would Subversion save any time?
30 Solutions collect form web for “Is Version Control necessary for a small development group (1-2 programmers)?”
I’m just gonna pile on here and say YES. Like @17 of 26 said
Not having some sort of source control is pure insanity.
This is truth. I’ve done small projects both with and without source control (not my choice). Without, it just sucks. There is no canonical version of the project, you never know who has what and merging changes is an exercise in pain.
Really though, anything over about 5 lines of code should be under version control of some sort.
You always, always want to have some sort of Source Control even if you are working on a project by yourself.
Having a history of changes is vital to being able to see the state of a codebase at any given time. There are a variety of reasons for looking back in a project history which range from just being able to rollback a bad change to providing support for an old release when the customer just wants a patch to fix a bug rather than upgrading to a newer version of the software.
Not having some sort of source control is pure insanity.
Even if you are a single programmer, you need version control. The simplicity with which you can compare the code to any snapshot in time is priceless.
My advice – go for it!
[Once I was living without version control. Now I cannot anymore.]
I am ONE programmer and I find it invaluable, as I sometimes want to roll things back, or compare something to an earlier version.
Also, I version documents from users and things like that.
It’s a great way to track your development.
Version control will save your ass. A professional developer not using version control is one of the few things that inarguably falls under the category of software malpractice.
Even if you are a lone developer it will
- Let you get back to when a feature worked
- Automatically maintain a backup: check it in and it’s backed up.
- Let you undo your local changes when you have gotten yourself tied in a knot.
- Let you go back to the version that is running in production, in the test environment or on a particular customer’s environment for debugging.
- If used properly it will also let you see all changes related to a fix for a particular problem which can be an invaluable debugging tool.
If you are more than one developer it will keep one programmer from overwriting the changes made another programmer which will happen no matter how careful you are.
These are just the basics that should help you win any argument about whether or not to use version control.
Subversion — absolutely not. It is centralized and merging support is not so good.
Version control — absolutely YES! Even solo developer needs it!
And small and fast moving, mobile teams needs distributed version control, so pick one of the following:
Yes, there is a learning curve. Go distributed, you can learn it. And yes, you can thank me later.
And where those distributed repositories live? Here are some ideas:
- in your personal USB memory stick (and dont limit yourself to one USB stick, distribute them also into multiple locations, like safety deposit box in your bank)
- another in safe place (offsite, different location, other side of net) where fires, earthquakes or tornadoes cannot harm your source simultaneously) as a backup
- one in centralized server, yours or something like github
- multiple copies in developer machines
- staging repository somewhere near staging server
- production repository somewhere near production site
I am a “one man band” programmer and I finally started using version control when I found myself copying whole applications and putting them into a folder called “backup” and then later naming them something like “20080122-backup”. I imagine a lot of people start this way. So the question is not whether or not you should use version control but rather should you do it the right way or should you hack together some half-assed homemade facsimile?
Version control is only necessary where the number of programmers is > 0.
Use whatever system works and you’re comfortable with but if you do development then you need version control (ideally set up in such a way that the source is on at least two machines even before you worry about backups).
Beyond that – look for a system that lets you commit early and commit often.
I’m almost – odd though it may sound – heading towards the view that every project, even a 1 dev one – should be looking at continuous integration i.e. having this system built and tested, from scratch, each time changes are committed or at least on a regular basis. Why? This a) gives you confidence that you have a buildable system in VCS and b) makes sure that you actually have a clean builds to test and deploy.
I don’t know about Subversion in particular, but I believe that every project, even one with a single developer, should use version control. I would look at a few options (CVS, SubVersion, git, Bazaar, Visual SourceSafe) and see which one(s) meet your team’s desires the best.
Version Control is the most important tool that a programmer has, even more important than the actual programming languages. No matter how many users you have, source control should always be required. I don’t know how many times I’ve made a breaking change and then needed to go back and work on old code or at least just see how the original code functioned. I work in small teams and we use SVN Notifier to let us know when things are commited. This allows us to review each others work and you don’t get the dreaded “Have you checked your code in yet?” questions all the time. Using source control from the beginning will eliminate many headaches (overwrites, lost code, fights over who changed what) that you may face.
Absolutely. There’s really no other way to deal with rollbacks to a known good state when the coding path you ventured down turns out to be dense with wolves.
And you can back it up.
I have a project that only I work on and Version Control makes my life so much easier. For example, say I decide to implement a new feature. For whatever reason though, I decide to trash it – maybe I wrote it wrong, maybe I changed my mind about implementing it, whatever. All I have to is revert to a previous version from SVN instead of manually reverting each file involved.
Subversion isn’t. But source control is.
Regardless if you are a single developer, or a group of developers you must do the following before you start coding ANYTHING:
- Set up a version control system.
Use whatever system you like, git,
SVN, Mercurial. It doesn’t matter as
long as you know how to use it.
- Set up a collaborative
documentation system. Use a Wiki
or a trac, or any other such system
you know how to use.
- Set up the build system. Use
Make, ANT, Maven, or any other build
system you know how to build.
- Write the first test cases.
Don’t code a single line of the main app until you have done these four
Anyone who isn’t doing version control is simply doing it wrong.
Version Control can have the following advantages:
- Rollback is always handy as you mentioned
- With some you can pin a previous version and run off of it without rolling back
- Helps prevent two people from working on a page at the same time which can cause several problems
But then again it also has its downfalls if you dont choose a good one
I strongly recommend source code control no matter what the size of the team. I have had too many late night sessions where I broke my code and did not have source code control to go to for older working versions.
Sorry for yelling 🙂
Version control is not only usefull for rolling back versions. It will give a lot of safety against rolling out older versions of files or accidentally overwriting newer versions with older versions etc.
One thing I’m only now getting used to that’s really usefull is the ability to branch and merge different versions. If you have a deadline coming up but you’re working on a new feature that’s not ready for prime time you can just branch before you started adding that feature. Create a deliverable version without that feature and merge those two after the deadline passes without problems.
Of course version control is necessary even for a one man project.
The option to save contexts and not just changes in the code is the great thing that source control does, you go from “file this and that changed in line blah” to “I added a new option to do …” which is really valuable.
Don’t listen to me though there’s a great article that rands wrote about this
YES, but only for developer teams where size is > 0
When i shut down my IDE/text editor/whatever and come back the next day to realize i want to undo may last boneheaded mistake, Source control is there for me to fall back on, or use to branch and perform some wild experiment on my code. Without source control I cannot do these things so freely.
For teams of size > 1 you have a central backup, you have team wide undo, it’s easier (possible) to work distributed, which when team size exceeds 1 is really what you’re doing anyway no matter how far away your team mates are.
I would argue for git, for two primary reasons
- trivial to set up repo. cd into the directory, git init, and you’re done
- logging! using a vcs of any kind makes it easy / obvious / simple to log why you’re making changes. having a dvcs in particular makes it really fast and easy to see when, what, and why one made changes. Since a dvcs has long information locally, it’s fast and easy to look up, unlike svn on remote machines.
[these are apparently true for Mercurial as well. They sure the heck aren’t so easy for subversion.]
Everyone who is saying that source control for 1-2 developers is a must is completely, completely right. Trust us 🙂
Back in college I had a professor who made us use source control. We all kicked and screamed, because CVS seemed way too complicated and sounded like overkill for student projects. Eventually we all came around, and even for simple projects from then on I’d put them all in source control. I’ve continued that to this day, and have saved myself from many hours of frustration.
Simple answer YES.
Not to reiterate, but it cannot be said enough. You SHOULD HAVE source control. Subversion is ridiculously easy and almost zero overhead once it is setup. It literally shouldn’t take more than 5-20 minutes to setup. You have other choices too, like GIT. So just pick one, and put your source in there – end of answer. 🙂
Version Control YES, you always need to perform version control.
SVN? no.. me, I use Git.
When I wish to go to the shops, I take my car to transport the shopping home. It is not necessary to put gas in my car. I could choose to push the car instead, but why would I?
Likewise with choosing not to use version control….
There will be some time-loss when you set up the system and instuct the other developers – especially if they are not familiar with versioncontrol (or subversion in specific).
But the benefits of being able to roll-back to a previous (working) version and the possibility to do a easy diff of checked in files will be more than worth it.
The biggest problem is that the rewards -like most things- come after the ‘hard work’. 🙂
Note, a different, but more lightweight solution may be enabeling ‘Shadow Copy’ on Windows, if that’s your server os (although I guess it won’t be). The plus of this is that you won’t be bothering your co-developers with learning subversion, but you will be able to revert to a older version when needed…
Version control should be the first thing you think about when starting a project. Second is automatic builds, third is testing, fourth is incorporating your tests with your builds.
VSS is fine but mucho dinero.
try mercurial (hg) instead of svn
Yes, if you are a professional developer then you absolutely need to be using version control!