When to use Version Control?

Question

Possible Duplicate:
Do I really need version control?

I am a lone developer, developing Web Sites/Apps in PHP. I dont work with anybody, I use a framework so I dont create libraries for my apps (most of the time).

I have read a lot about Version Control and its benefits, but I dont understand how it would benefit somebody like me.

The biggest benefit I can see it having is that if I posted the code on a remote server I could work from anywhere on any computer, but I carry my laptop like I carry my phone so again I dont see much of a reason there.

Can somebody please explain to me in a simple manner the reasons for going with a VCS, and give me some good free ones I should try? Are there any hidden benefits/scenarios that you can think of that may sway me in any direction one way or the other.

Thanks

Answer 1

rolling back? Getting that previous working version that you broke.

Even when coding alone, sometimes you decide to "try something" and this attempt simply doesn't work. Sometimes this attempt involves making big, not trivial changes, which would be hard to just undo them. Having a version control is great in this sense, once you can rollback a lot.

Additionally, you can have branches of your code, so you can try different stuff and run both of them and compare,

Answer 2

The huge benefit is that you can roll back any changes you make to your code that end up being bad decisions. With your current "Backup whenever I remember" method (if you're doing backups at all), the best you can do if you mess up your code is restore the last backup. With source control, it's easy to compare to the last check-in, restore pieces, merge, or generally undo your mistakes.

Being able to recreate the source code at a particular version or at a particular point in time is also a big plus - if a customer calls and has a problem with a certain version and you don't have a backup of that exact version, you're hosed - but with source control, retrieving that exact version is a one-click operation.

Answer 3

So say you have v1.0 of your site. Its all running great, and now you are working on a huge upgrade to 2.0. However while in the middle of getting 2.0 finished you are made aware of a critical bug to 1.0. You can't just roll out 2.0 with the fix as it's only 1/2 finished. You could make the fix for 1.0 but you don't have 1.0's code behind any more because no version control.

You can easily try different changes and not worry about loosing how you had it before as long as you checked in your changes before each modification.

I prefer SVN. I know there are more advanced ones out there, but SVN is ambiguous and virtually all tools support it.

Answer 4

You should always use version control, even if you're developing alone.

By using version control, you keep track of different versions of each file, making it easy to -for instance- rollback changes that you've made, Or, see what you've changed to a certain class between 2 releases.

Also, it is easy to backup your code when you're using a version-control system. Some people say: 'the code doesn't exists when it is not checked in into a VSS system', and they're damn right about it.

If you're developing some kind of software that is used by other developers in their software, you can even benefit from the fact that those other developers can step into your code while debugging. Ofcourse, you'll need a symbol server to achieve that, but, you also need a version control system, because you want to make sure that those developers can step into your code, no matter which build they use of your package, and all the versions of your code can offcourse be found into the version control system. :)

Answer 5

The fact that you can track your changes, easily deploy your code, perform merges and diffs, and leave comments on your changes. I can't believe that people still program without version control. Check out subversion or github.

Answer 6

For an individual developer, one of the big reasons to use version control is to allow you to backtrack to previous versions of your code, or create branches to try different solutions out without worrying about pushing your program into a broken state.

As for a good version control tool, I love Fossil for projects where I am the sole developer, mainly for its ease of use. Its really easy to use... self contained in a single executable, and integrates bug tracking and wiki documentation.

Answer 7

I would never consider working without version control, even on a solo project, for the following reasons:

1. it gives me a place to make annotations on what I changed, and why, together with exactly what the changes were, without much effort on my part. This creates a history for my project, including every day's work.

2. it gives me a time machine, so I can fly back in time and see what code a particular customer received, or what code I fixed on a particular day.

3. it makes it easier to share my work and pass it to another developer when they need to help me.

4. if the project team grows in size from 1 (me) to 2 or 10 people, I don't have to do anything differently.

5. Because I use a distributed version control system (mercurial) I didn't have to set up any servers, or do anything complicated to get started.

Answer 8

Code evolves. As a project moves from first-cut prototype to deliverable, it goes through multiple cycles in which you explore new ground, debug, and then stabilize what you've accomplished. And this evolution doesn't stop when you first deliver for production. Most projects will need to be maintained and enhanced past the 1.0 stage, and will be released multiple times. Tracking all that detail is just the sort of thing computers are good at and humans are not.

From http://www.faqs.org/docs/artu/ch15s05.html.

The text answers also the question, 'Why Version Control?'

The tools suggested are a little outdated, you can look at:

• Mercurial
• git
• Bazaar
• Darcs
• Subversion
• and others ...

Answer 9

In your situation it can be handy to protect you from overwritting your files. It's also handy to allow you to branch off when you want to see if new techniques you want to try out work without copying and pasting folders of different versions of the site.

It would make rolling back to a fully working version of your site a super easy thing to do in the off chance that you overwrite the local or remote files.

Answer 10

Especially as a lone developer, a VCS is a good idea, since whenever you are working on something you are potentially breaking it as well. (And you're the only person you can go to to see if you remember why this change might be breaking things). It let's you make changes without having to back your code up into a _backup_YYYY_MM_DD folder, and thus saves you from project clutter.

You can setup a base project, or a series of base projects in source control and then as you make improvements to them you can pull the best parts of them into your old projects with merge (and without a good deal of the hard work that would be involved with doing it by hand.)

In addition, as others have pointed out, it gives you a log of your day to day work, a notebook and an overview of how your code base is evolving, and the freedom to experiment more readily.

There's no reason not to and many good reasons to do so -- so jump on the bandwagon! (I recommend Git) ;-)

Answer 11

Learn SVN, for the reasons given above. (there is the tortoise gui for windows which is really easy) People may argue that git or something is better, but for now you will be fine.

The most important things you can do are: update, commit, revert, add, remove and move.. Also learn what a conflict is and think about when it could happen. This should not take long and will be useful in the future.

Answer 12

1. History for your code. If you mess up one of your classes, you can always go back in time.
2. Documentation of the evolution of your code and what each change involves (assuming you do put proper commit descriptions)
3. Backup (with the remote VCS hosting). If your laptop dies, you still have (hopoefuly, a recent) version of your software somewhere.
4. Incremental and side-by-side changes. You can work on small units of your code and focus on particular tasks and always know what the changes involve by looking at the diff of the working copy and the repo. You can also work on two separate unrelated changes in two working copies, without having to worry too much about keeping them in sync.
5. Easy onboarding of new developers (if you get to that point)
6. Ability to automate some parts of your process (continuous integration for example) against a clean copy of your code.
7. Bragging rights that you are "real" developer! :-) Or in business speak - you can now tell your clients that you are not just writing code for them, but you are delivering them a product that follows proper engineering practices. Might sound like a joke, but in fact it is an important part of being able to sell yourself and your services.