Is Subversion (Version Control) Necessary For A Small Development Group (1-2 programmers)?

Question

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?

Answer 1

Definite yes.

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.]

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

Version Control can have the following advantages:

1. Rollback is always handy as you mentioned
2. With some you can pin a previous version and run off of it without rolling back
3. 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

Answer 7

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.

Answer 8

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...

Answer 9

YES!

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.

Answer 10

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

Capturing Context

Answer 11

Even with a small team, version control like Subversion is important, not just to be able to compare between revisions but also to roll back to a previously working version.

But all of this comes with added complexity. Instead of just saving the code, it has to be checked into the system. Every major version control system has tools to easily check code in, and many will integrate directly with IDEs. However, this doesn't change the fact that there are additional steps that must be taken when saving code files. There is overhead in placing code in a version control system, but having working code to roll back to when a problem occurs can make up for this extra overhead.

Answer 12

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.

Answer 13

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:

• git
• mercurial
• darcs

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

Answer 14

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.

Answer 15

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.

Answer 16

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?

Answer 17

Subversion isn't. But source control is.

Answer 18

Source control doesn't cost you anything but the time of setting it up. It's just a no-brainer.

Answer 19

Yes, even if you are the only person source control is a must. Of course you will not be using it to control who is working on which files, but having the ability to role back if you make a big mistake in your code is really a no-brainer.

Answer 20

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.

Answer 21

I'd attempt to be the first to answer NO. It takes time to learn how to use it effectively. And it can be confusing to new users. Rolling back? Merging your changes together? being able to branch your project? or be sure that all this stuff you are deleting now is NOT going to be lost forever? Its helpful in only a few cases, and I'm not 100% sure that the 10 minutes it takes to find SVN or TortoiseSVN and download it, + the 30 min to learn a little about the use is worth it.

OTOH: Is. Your. partner. *)&%$#. crazy?

We have several possible tools for use at work. No broad support for either CVS or SVN but rather a commercial relative for most things.. I use tortoiseSVN on my pc to handle my own WORD documents and spreadsheets, and I find that the MERGE capability really helps when others edit my spreadsheets and send them back to me. (I tend to do the merge by saving the different versions as an xml spreadsheet. ) or to back up changes when I use a doc or spreadsheet on more than one PC.

However ARGUING about it doesn't work. Show her/him how to install it, and demonstrate a little editing of the same document. Or let them train themselves at software carpentry.

Answer 22

Is Visual SourceSafe an option? I am a single programmer and have been using it as a repositry for the last while with no problems but I keep hearing about horror stories. Is it really that bad?

Answer 23

Regardless if you are a single developer, or a group of developers you must do the following before you start coding ANYTHING:

1. 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.
2. Set up a collaborative documentation system. Use a Wiki or a trac, or any other such system you know how to use.
3. Set up the build system. Use Make, ANT, Maven, or any other build system you know how to build.
4. Write the first test cases.

Don't code a single line of the main app until you have done these four

Answer 24

VSS is fine but mucho dinero.

Answer 25

try mercurial (hg) instead of svn

Answer 26

Anyone who isn't doing version control is simply doing it wrong.

Answer 27

Yes, if you are a professional developer then you absolutely need to be using version control!

Answer 28

I'm just throwing this out there, but I believe PERFORCE is free for up to 2 developers. Don't know how easy it is to set up.

I would guess you'd want something that's easy to set up and use.

Answer 29

The original 'rcs' tool is still out there and still works (on unix and windows/dos) and is possibly the simplest of these tools, which is why I'd recommend it for a two-man team working on the same system (eg same office, same fileserver or unix host). It's only worth getting into a client/server model like subversion if you're working in separate environments.

Answer 30

you need source control if at least ONE of the following is true:

1) there are more than ONE developer

2) the project is more than ONE mounth long

3) the project has more than 5000 lines of code

so, if you are two persons you need to use version control. Also if you are alone but your project reach a not trivial complexity... you need version control!

Answer 31

I would argue for git, for two primary reasons

1. trivial to set up repo. cd into the directory, git init, and you're done
2. 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.]

Answer 32

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.

Answer 33

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.

Answer 34

Source control will give you peace of mind. I'm a mISV, and lost my system hard drive earlier this week. My code is in several Subversion repositories. I had just finished re-organizing the code, so that I could just check out and go.

I'm waiting for the new hard drive to arrive. I have the peace of mind that when the new hard drive gets here, I will be able to continue enhancing my product where I left off.

Answer 35

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.

Answer 36

Yes, source control is a must.

I use Sourcegear Vault which is free for a single developer.

Answer 37

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.

Answer 38

Source Control YES. Subversion NO

Subversion is appropriate for really complex stuff that needs to handle branching REALLY well. Otherwise it is not worth the effort of learning and maintaining it.

There's plenty of other more straightforward source control at a small size (I personally recommend PerForce)

BTW I would rank Creating a build system is more important than version control.

Now, with so few people it IS possible to manage source control by splitting up your work files carefully, but this does not give you version control (which is essentially automatically built into any source control you will find) At the very very least you need to be able to look back and find a version of your file from a few weeks.

Answer 39

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. :)

Answer 40

Subversion is not overkill for small groups and but should not be thought of as a replacement for proper project management. Long story short- if people don't have a schedule and proper communication, use of version control is not much better not using and can cause more problems than it aims to solve. Questions you should answer while implementing version control:

• Who is responsible for managing the repository?
• Do you have a release schedule? How do you communicate merging changes?
• What is the difference between your current source management (files, copies on a filesystem) and what you aim to accomplish with subversion?(hint, if you don't have a clear answer, don't use it).
• How specifically will your use of subversion be incorporated in your project management plans?

Answer 41

Version Control YES, you always need to perform version control.

SVN? no.. me, I use Git.

Answer 42

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....