Will using a VCS help me as a web dev?

Question

I'm thinking of trying a VCS such as subversion, to manage my next project, but I'm not sure if will offer any real benefits for me as a web developer. As I understand it, one of the major benefits of a VCS is that a group of people can work on a project at once.

Reading material on the subject seems pretty one sided:

"Using a version control system is an absolute must for a developer of a project above a few hundred lines of code"

...and I've got a feeling it could become a chore, with not many benefits.

I work on development server on the local network, so any amount of people can work on the files already. If anyone needs to get in remotely, they use FTP. What would a modern version control system give me on top of this?

Answer 1

A version control system is a must even if you're working alone, because it allows you to keep a history of your changes - which in turn gives you the freedom to experiment, because you know you can always get back to a previous working version.

I now use subversion even for "test" projects that are less than 100 lines. You never know :)

Answer 2

In your situation it can give you at least four additional benefits:

1) It will serve as additional backup storage.
2) If you accidentally add bugs you can easily return to the previous stable version.
3) If you accidentally add a bug or break something - you can see differences between your current source code and last commited source code - the VCS will show you the differences in a very suitable and demonstrative way - and you will easily find the change that caused the bug or the problem. This one is very useful.
4) You can easily review your modifications before committing. Believe me, you can be surprised :) Sometimes you just do something automatically, not thinking very much, or you can be tired. In this case, if you review your modifications later - you can find mistakes or bad code.

Good luck!

Answer 3

As I see it, VCS systems are even more useful in web environments because of the ease with which "anyone" can edit the site.

Every web project I've ever worked on has suffered from the "too many cooks in the kitchen" syndrome, where eventually someone goes to add one little feature, and then you go back and look and discover that they ended up rewriting some huge chunk of the site and broke something else. Having a stack of versions in a VCS makes troubleshooting those kinds of bugs as close to trivial as you can get.

Also, VCS makes deployment of web apps a breeze. Tag the production version of all the pages in the VCS as such, and then just check out to the web server. So much better than the "traditional" method of one guy with a list of changed files and an FTP client.

Answer 4

Another benefit I found of source control is that it helps you be more organized. Prior to using SCM I would jump around making small changes. With SCM and the need for sensible check-ins I've become more considered and structured in what I write.

Answer 5

I'm late on this one, but just want to add some bullets to the list nightcoder started: These are ways that SVN has benefited me.

Nightcoder wrote:

1) ...backup storage.

2) ...return to the previous stable version.

3) ...see differences between your current source code and last committed source code....

Additionally:

4) From a single, short comment in the SVN log, you can see who committed the change, when, and why.

• No sifting through comments in the code (unless you want to).
• Why is that? Because each time you commit, you are asked to comment the change. That taciturn comment is logged.

5) The '$id$' added (at your option) into the file itself is a fantastic reference point.

• Does it match the id of the version you have on your desktop?
  • No more having to run a difference check on two (or 3 or 4!) same-named files.
• Does it match the id of the same-named file you have running on a different server/different domain?
  • No? Then one server/domain is not using the latest version-- fix that.
• $id$ makes a handy 'version' reference in an x/html document meta-tag.

6) No more sifting through date-stamped backups to find working copies (see also, 2).

7) Add your code easily to Google code to share with the world or get help from others.

• Google code currently uses SVN.

8) As others have said, organization, organization, organization.

• Before using SVN, I thought I was well organized. I was wrong.

9) In a multi-user environment, synchronization of current versions is a snap.

• This in-built synchronization system may be the primary reason organizations swear by such a system, in a mult-developer environment.

Downside:

• Learning curve may be fairly steep unless you're terminal-language oriented. The lingo is not like Perl/Java/PHP/etc.
• Initial set up can be confusing. Reading and following directions is imperative.

Overall, well worth the week you will spend emersed in setting up and learning the system.

Answer 6

another reason: sharing between working environments.

i use svn not only for my important projects but also for the throw-away sandbox scripts (where i'm the only coder). for projects i have different repositories, and then there's the "sandbox" repository. all the throwaway-code goes in there.

the reason for this is, i edit the code from different places - work and home - and it makes sharing easy. no emailing around code via archives or loading them up somewhere. at work, i just commit, go home, update and continue. you shouldn't do this for important projects tough (only commit working scripts). if i forgot to commit at the end of the day, i can at least work on the code and then merge the edits together the next day.

i do this not only for code, but for all kinds of (small) files that are important to me. if i write a comment somewhere i'm proud of, but i know will be forgotten in a week, i save a copy to the sandbox (kind of a shared "my documents") - for nostalgic reasons. same for stories, brainstorms, ideas, todo-lists and so on.

there are lots of other advantages to vcs:

• quick access to your stuff from everywhere (if it's a public server). if you only need to read code, a browser is enough (if the server supports it).
• hosting on a server. all disks in my personal computers died sooner or later, often taking years of scripts with them. yes, i'm sure, somewhere in the cellar are backups on cds or zip disks, and i'm also sure i'll never find them again (also, i don't own a zip drive anymore, and you know the lifespan of cds ...). the cvs-servers all have raid, professional admins, backups, ... and if the company is going out of business you at least have a copy of the code locally.
• you can run automated scripts when committing. i've never used this tough.
• keeping the codebases working. there are 3 copies of your app: local, in the repository and the webserver. if you didn't finish the work at the end of your shift, don't commit, so the repository doesn't includes broken code. if you made all changes and tests, export them to the webserver. this way, (in a perfect world) the webserver never hosts broken code.
• granting/revoking access to others. you can do this with ftp too, but this way it's easier to track changes they made.

Answer 7

You can try a new feature on a new branch and if it doesn't work as you expected you can discard the test branch and revert back to the original working branch, pretty handy for coders.