A Visual Guide to Version Control

Version Control (aka Revision Control aka Source Control) lets you track your files over time. Why do you care? So when you mess up you can easily get back to a previous working version.

You’ve probably cooked up your own version control system without realizing it had such a geeky name. Got any files like this? (Not these exact ones I hope).

  • KalidAzadResumeOct2006.doc
  • KalidAzadResumeMar2007.doc
  • instacalc-logo3.png
  • instacalc-logo4.png
  • logo-old.png

It’s why we use “Save As”. You want the new file without obliterating the old one. It’s a common problem, and solutions are usually like this:

  • Make a single backup copy (Document.old.txt).
  • If we’re clever, we add a version number or date: Document_V1.txt, DocumentMarch2007.txt
  • We may even use a shared folder so other people can see and edit files without sending them over email. Hopefully they relabel the file after they save it.

So Why Do We Need A Version Control System (VCS)?

Our shared folder/naming system is fine for class projects or one-time papers. But software projects? Not a chance.

Do you think the Windows source code sits in a shared folder like “Windows2007-Latest-UPDATED!!”, for anyone to edit? That every programmer just works in a different subfolder? No way.

Large, fast-changing projects with many authors need a Version Control System (geekspeak for “file database”) to track changes and avoid general chaos. A good VCS does the following:

  • Backup and Restore. Files are saved as they are edited, and you can jump to any moment in time. Need that file as it was on Feb 23, 2007? No problem.
  • Synchronization. Lets people share files and stay up-to-date with the latest version.
  • Short-term undo. Monkeying with a file and messed it up? (That’s just like you, isn’t it?). Throw away your changes and go back to the “last known good” version in the database.
  • Long-term undo. Sometimes we mess up bad. Suppose you made a change a year ago, and it had a bug. Jump back to the old version, and see what change was made that day.
  • Track Changes. As files are updated, you can leave messages explaining why the change happened (stored in the VCS, not the file). This makes it easy to see how a file is evolving over time, and why.
  • Track Ownership. A VCS tags every change with the name of the person who made it. Helpful for blamestorming giving credit.
  • Sandboxing, or insurance against yourself. Making a big change? You can make temporary changes in an isolated area, test and work out the kinks before “checking in” your changes.
  • Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolation (tracking changes separately). Later, you can merge your work back into the common area.

Shared folders are quick and simple, but can’t beat these features.

Learn the Lingo

Most version control systems involve the following concepts, though the labels may be different.

Basic Setup

  • Repository (repo): The database storing the files.
  • Server: The computer storing the repo.
  • Client: The computer connecting to the repo.
  • Working Set/Working Copy: Your local directory of files, where you make changes.
  • Trunk/Main: The “primary” location for code in the repo. Think of code as a family tree — the “trunk” is the main line.

Basic Actions

  • Add: Put a file into the repo for the first time, i.e. begin tracking it with Version Control.
  • Revision: What version a file is on (v1, v2, v3, etc.).
  • Head: The latest revision in the repo.
  • Check out: Download a file from the repo.
  • Check in: Upload a file to the repository (if it has changed). The file gets a new revision number, and people can “check out” the latest one.
  • Checkin Message: A short message describing what was changed.
  • Changelog/History: A list of changes made to a file since it was created.
  • Update/Sync: Synchronize your files with the latest from the repository. This lets you grab the latest revisions of all files.
  • Revert: Throw away your local changes and reload the latest version from the repository.

Advanced Actions

  • Branch: Create a separate copy of a file/folder for private use (bug fixing, testing, etc). Branch is both a verb (”branch the code”) and a noun (”Which branch is it in?”).
  • Diff/Change/Delta: Finding the differences between two files. Useful for seeing what changed between revisions.
  • Merge (or patch): Apply the changes from one file to another, to bring it up-to-date. For example, you can merge features from one branch into another. (At Microsoft this was called Reverse Integrate and Forward Integrate)
  • Conflict: When pending changes to a file contradict each other (both changes cannot be applied).
  • Resolve: Fixing the changes that contradict each other and checking in the correct version.
  • Locking: “Taking control” of a file so nobody else can edit it until you unlock it. Some version control systems use this to avoid conflicts.
  • Breaking the lock: Forcibly unlocking a file so you can edit it. It may be needed if someone locks a file and goes on vacation (or “calls in sick” the day Halo 3 comes out).
  • Check out for edit: Checking out an “editable” version of a file. Some VCSes have editable files by default, others require an explicit command.

And a typical scenario goes like this:

Alice adds a file (list.txt) to the repository. She checks it out, makes a change (puts “milk” on the list), and checks it back in with a checkin message (”Added required item.”). The next morning, Bob updates his local working set and sees the latest revision of list.txt, which contains “milk”. He can browse the changelog or diff to see that Alice put “milk” the day before.

Visual Examples

This guide is purposefully high-level: most tutorials throw a bunch of text commands at you. I prefer to cover the high-level concepts without getting stuck in the syntax (the manual is always there, don’t worry). Sometimes it’s nice to see what’s possible.

Checkins

The simplest scenario is checking in a file (list.txt) and modifying it over time.

version control checkin

Each time we check in a new version, we get a new revision (r1, r2, r3, etc.).

svn add list.txt
(modify the file)
svn ci list.txt -m "Changed the list"

The -m flag is the message to use for this checkin.

Checkouts and Editing

In reality, you might not keep checking in a file. You may have to check out, edit and check in. The cycle looks like this:

version control checkout

If you don’t like your changes and want to start over, you can revert to the previous version and start again (or stop). When checking out, you get the latest revision by default. If you want, you can specify a particular revision. In Subversion, run:


svn co list.txt (get latest version)
...edit file...
svn revert list.txt (throw away changes)

svn co -r2 list.txt (check out particular version)

Diffs

The trunk has a history of changes as a file evolves. Diffs are the changes you made while editing: imagine you can “peel” them off and apply them to a file:

version control diff

For example, to go from r1 to r2, we add eggs (+Eggs). Imagine peeling off that red sticker and placing it on r1, to get r2.

And to get from r2 to r3, we add Juice (+Juice). To get from r3 to r4, we remove Juice and add Soup (-Juice, +Soup).

Most version control systems store diffs rather than full copies of the file. This saves disk space: 4 revisions of a file doesn’t mean we have 4 copies; we have 1 copy and 4 small diffs. Pretty nifty, eh? In SVN, we diff two revisions of a file like this:

svn diff -r3:4 list.txt

Diffs help us notice changes (”How did you fix that bug again?”) and even apply them from one branch to another.

Bonus question: what’s the diff from r1 to r4?

+Eggs
+Soup

Notice how “Juice” wasn’t even involved — the direct jump from r1 to r4 doesn’t need that change, since Juice was overridden by Soup.

Branching

Branches let us copy code into a separate folder so we can monkey with it separately:

version control branch

For example, we can create a branch for new, experimental ideas for our list: crazy things like Rice or Eggo waffles. Depending on the version control system, creating a branch (copy) may change the revision number.

Now that we have a branch, we can change our code and work out the kinks. (“Hrm… waffles? I don’t know what the boss will think. Rice is a safe bet.”). Since we’re in a separate branch, we can make changes and test in isolation, knowing our changes won’t hurt anyone. And our branch history is under version control.

In Subversion, you create a branch simply by copying a directory to another.

svn copy http://path/to/trunk http://path/to/branch

So branching isn’t too tough of a concept: Pretend you copied your code into a different directory. You’ve probably branched your code in school projects, making sure you have a “fail safe” version you can return to if things blow up.

Merging

Branching sounds simple, right? Well, it’s not — figuring out how to merge changes from one branch to another can be tricky.

Let’s say we want to get the “Rice” feature from our experimental branch into the mainline. How would we do this? Diff r6 and r7 and apply that to the main line?

Wrongo. We only want to apply the changes that happened in the branch!. That means we diff r5 and r6, and apply that to the main trunk:

version control merge

If we diffed r6 and r7, we would lose the “Bread” feature that was in main. This is a subtle point — imagine “peeling off” the changes from the experimental branch (+Rice) and adding that to main. Main may have had other changes, which is ok — we just want to insert the Rice feature.

In Subversion, merging is very close to diffing. Inside the main trunk, run the command: 

svn merge -r5:6 http://path/to/branch

This command diffs r5-r6 in the experimental branch and applies it to the current location. Unfortunately, Subversion doesn’t have an easy way to keep track of what merges have been applied, so if you’re not careful you may apply the same changes twice. It’s a planned feature, but the current advice is to keep a changelog message reminding you that you’ve already merged r5-r6 into main.

Conflicts

Many times, the VCS can automatically merge changes to different parts of a file. Conflicts can arise when changes appear that don’t gel: Joe wants to remove eggs and replace it with cheese (-eggs, +cheese), and Sue wants to replace eggs with a hot dog (-eggs, +hot dog).

version control conflict

At this point it’s a race: if Joe checks in first, that’s the change that goes through (and Sue can’t make her change).

When changes overlap and contradict like this, the VCS may report a conflict and not let you check in — it’s up to you to check in a newer version that resolves this dilemma. A few approaches:

  • Re-apply your changes. Sync to the the latest version (r4) and re-apply your changes to this file: Add hot dog to the list that already has cheese.
  • Override their changes with yours. Check out the latest version (r4), copy over your version, and check your version in. In effect, this removes cheese and replaces it with hot dog.

Conflicts are infrequent but can be a pain. Usually I update to the latest and re-apply my changes.

Tagging

Who would have thought a version control system would be Web 2.0 compliant? Many systems let you tag (label) any revision for easy reference. This way you can refer to “Release 1.0″ instead of a particular build number:

version control tag

In Subversion, tags are just branches that you agree not to edit; they are around for posterity, so you can see exactly what your version 1.0 release contained. Hence they end in a stub — there’s nowhere to go.

(in trunk)
svn copy http://path/to/revision http://path/to/tag

Real-life example: Managing Windows Source Code

We guessed that Windows was managed out of a shared folder, but it’s not the case. So how’s it done?

  • There’s a main line with stable builds of Windows.
  • Each group (Networking, User Interface, Media Player, etc.) has its own branch to develop new features. These are under development and less stable than main.

You develop new features in your branch and “Reverse Integrate (RI)” to get them into Main. Later, you “Forward Integrate” and to get the latest changes from Main into your branch:

version control branch example

Let’s say we’re at Media Player 10 and IE 6. The Media Player team makes version 11 in their own branch. When it’s ready and tested, there’s a patch from 10 - 11 which is applied to Main (just like the “Rice” example, but a tad more complicated). This a reverse integration, from the branch to the trunk. The IE team can do the same thing.

Later, the Media Player team can pick up the latest code from other teams, like IE. In this case, Media Player forward integrates and gets the latest patches from main into their branch. This is like pulling in the “Bread” feature into the experimental branch, but again, more complicated.

So it’s RI and FI. Aye aye. This arrangement lets changes percolate throughout the branches, while keeping new code out of the main line. Cool, eh?

In reality, there’s many layers of branches and sub-branches, along with quality metrics that determine when you get to RI. But you get the idea: branches help manage complexity. Now you know the basics of how one of the largest software projects is organized.

Key Takeaways

My goal was to share high-level thoughts about version control systems. Here are the basics:

  • Use version control. Seriously, it’s a good thing, even if you’re not writing an OS. It’s worth it for backups alone.
  • Take it slow. I’m only now looking into branching and merging for my projects. Just get a handle on using version control and go from there. If you’re a small project, branching/merging may not be an issue. Large projects often have experienced maintainers who keep track of the branches and patches.
  • Keep Learning. There’s plenty of guides for SVN, CVS, RCS, Git, Perforce or whatever system you’re using. The important thing is to know the concepts and realize every system has its own lingo and philosophy. Eric Sink has a detailed version control guide also.

These are the basics — as time goes on I’ll share specific lessons I’ve learned from my projects. Now that you’ve figured out a regular VCS, try an illustrated guide to distributed version control.


Posted September 27, 2007, under Guides, Programming
Tags: , , , , , , , , , ,
Related Posts:
  • Explanations for everyone.
  • What do you want Better Explained?
  • Intro to Distributed Version Control (Illustrated)
  • How To Optimize Your Site With HTTP Caching
  • Keeping your data backed up
    • Like it? Share on:
    • StumbleUpon
    • Digg
    • del.icio.us
    • Reddit
    Tools of the trade:
    Book Cover
    Don't Make Me Think
    (Web Design)
    Book Cover
    On Writing Well
    (Writing Style)
    Book Cover
    MS Office 2007
    (Charts & Diagrams)

    119 Comments »

    Trackbacks & Pingbacks

    1. Pingback by Visual guide to version control « Dyan’s Weblog — September 28, 2007 @ 7:11 am

    2. Pingback by digresjon.net | Guide til subversion — September 28, 2007 @ 1:54 pm

    3. Pingback by The Abarentos Narrative » links for 2007-09-28 — September 28, 2007 @ 4:17 pm

    4. Pingback by joet3ch.com » Version Control — September 28, 2007 @ 4:22 pm

    5. Pingback by links for 2007-09-28 at graemef.com — September 28, 2007 @ 4:36 pm

    6. Pingback by Version Control Explained < Nerdpocalypse — September 28, 2007 @ 5:02 pm

    7. Pingback by links for 2007-09-29 « Simply… A User — September 28, 2007 @ 5:32 pm

    8. Pingback by Art, Algorithms, and Design» Blog Archive » Basic Intro to Version Control - Subversion/SVN — September 28, 2007 @ 7:22 pm

    9. Pingback by Karl’s Place » Blog Archive » Cool site: BetterExplained.com — September 28, 2007 @ 7:24 pm

    10. Pingback by links for 2007-09-29 « Donghai Ma — September 28, 2007 @ 9:17 pm

    11. Pingback by Intro to VCS « A Programmer’s Ramblings … — September 29, 2007 @ 2:39 am

    12. Pingback by Version Control: Get a better understanding of version control … | Tolagomi News — September 29, 2007 @ 5:08 am

    13. Pingback by links for 2007-09-29 « D e j a m e S e r — September 29, 2007 @ 8:20 am

    14. Pingback by Sam’s Updates » Blog Archive » links for 2007-09-29 — September 29, 2007 @ 8:26 am

    15. Pingback by Craig Vidler | Weblog » links for 2007-09-29 — September 29, 2007 @ 11:18 am

    16. Pingback by christian schorn » Blog Archive » Links vom 29.09.2007 — September 29, 2007 @ 2:19 pm

    17. Pingback by links for 2007-09-29 « steinarcarlsen — September 29, 2007 @ 2:22 pm

    18. Pingback by Best of Feeds - 30 links - programming, productivity, code, socialsoftware, socialnetworking « Internet Duct Tape — September 29, 2007 @ 5:46 pm

    19. Pingback by links for 2007-09-30 « Mandarine — September 29, 2007 @ 9:27 pm

    20. Pingback by links, ideas and geek stuff » Blog Archive » links for 2007-10-01 — September 30, 2007 @ 5:33 pm

    21. Pingback by Phil Gainley » Blog Archive » A Visual Guide To Version Control With Phil Gainley — October 1, 2007 @ 12:14 am

    22. Pingback by A Visual Guide to Version Control | BetterExplained « vincenthome’s Software Development — October 5, 2007 @ 7:34 am

    23. Pingback by What do you want Better Explained? | BetterExplained — October 7, 2007 @ 10:52 am

    24. Pingback by Wagner Elias - Think Security First » Controle de Versão — October 10, 2007 @ 12:14 pm

    25. Pingback by A Visual Look at Distributed Version Control | BetterExplained — October 15, 2007 @ 12:01 am

    26. Pingback by links for 2007-10-17 — October 17, 2007 @ 4:18 pm

    27. Pingback by Revision Control 101 « Nano Taboada — October 17, 2007 @ 7:06 pm

    28. Pingback by links for 2007-12-13 at DeStructUred Blog — December 12, 2007 @ 7:19 pm

    29. Pingback by Backups « Bhushan G Ahire’s Weblog — December 13, 2007 @ 2:45 am

    30. Pingback by Principle #1 - Builds should be repeatable (Part 2) — Sauers Technologies — December 13, 2007 @ 5:12 am

    31. Pingback by Understanding Software Development « Panospace’s Weblog — January 20, 2008 @ 7:51 am

    32. Pingback by Mind Gravy » Blog Archive » links for 2008-01-24 — January 24, 2008 @ 5:28 am

    33. Pingback by Wildbit » Blog Archive » Visual Guide to Version Control – Social Networking and Subscriber-based Services. — February 13, 2008 @ 9:30 am

    34. Pingback by Effortless version control for teams and one-man developer shops alike | fonicmonkey — February 16, 2008 @ 3:22 am

    35. Pingback by RAILroading » Blog Archive » links for 2008-02-17 — February 16, 2008 @ 8:48 pm

    36. Pingback by a work on process » links for 2008-02-17 — February 16, 2008 @ 9:23 pm

    37. Pingback by Top of the Mountains » Blog Archive » Human-faced beanstalks — February 19, 2008 @ 4:02 pm

    38. Pingback by being (no)body » m3talink for February 24th through February 25th — February 25, 2008 @ 5:56 pm

    39. Pingback by A great intro guide to version control « kfarr — February 29, 2008 @ 11:01 pm

    40. Pingback by Subversion Obliterate, the forgotten feature — March 1, 2008 @ 1:28 pm

    41. Pingback by links for 2008-03-12 « D e j a m e S e r — March 12, 2008 @ 8:18 am

    42. Pingback by Revue de presse | Simple Entrepreneur — March 28, 2008 @ 11:47 pm

    43. Pingback by Incoherent Babbling » Blog Archive » Version Control Explained Simply — April 11, 2008 @ 4:34 pm

    44. Pingback by A Guide to Using Subversion - /dev/null — May 1, 2008 @ 11:36 am

    45. Pingback by Software By Richard » In the Trenches, What is the Best Source Control for My Team? — May 7, 2008 @ 11:48 pm

    46. Pingback by Get your development under control - all about version control — andrewmccall.com — July 22, 2008 @ 6:46 am

    47. Pingback by ScribbleWiki » Blog Archive » Code Management — August 4, 2008 @ 1:39 pm

    48. Pingback by Understanding Version Control Systems « 404 Tech Support — August 20, 2008 @ 3:48 pm

    49. Pingback by Version Control Explained « Frontier Label Web Development Blog — August 28, 2008 @ 12:32 pm

    50. Pingback by Guía visual para el control de versiones « Hermoso día… — August 29, 2008 @ 2:45 am

    51. Pingback by adaptive path » blog » Adaptive Path » Signposts for the Week Ending August 29, 2008 — August 29, 2008 @ 5:29 pm

    52. Pingback by nortypig » Blog Archive » A Visual Guide to Version Control — September 3, 2008 @ 4:23 am

    53. Pingback by Pragmatic Yankee » Blog Archive » links for 2008-09-04 — September 4, 2008 @ 11:03 am


    Comments

    1. I absolutely love a Friday but this article has made my day already! Thanks for putting this together…going to have a read of this later on today.
      C

      Carlton Dickson — September 28, 2007 @ 12:44 am

    2. Great dumbing down for the newbie I plan to share with the kids I mentor from time to time.

      Would have loved to see a link to Accurev guides as well. Found them here:
      http://www.accurev.com/documentation.html

      Some very interesting lingo/philosophy in the Accurev tool that takes SCM to the next level.

      Mark

      Mark — September 28, 2007 @ 8:24 am

    3. Great article Khalid, and thanks for the link to Eric’s articles, they were pretty good too!

      I will be testing the tagging and branching approach you both mention, it will mean I can check out a branch (i.e. previous release) into a new folder…make bug fixes and check it back into the branch and deploy to live server in a more controlled, and traceable way. Then would obviously need to merge bug fixes into my current trunk (development work since last version).

      Here is quite a useful resource for SVN and source control in general by the way http://svnbook.red-bean.com/

      Carlton Dickson — September 28, 2007 @ 8:47 am

    4. Hi Carlton, thanks for dropping by! Yep, I’m working out my own branching/merging scheme to make it easy to edit/update the live version while still doing new development. Let me know if you have any insights :)

      Hi Mark, thanks for the comment and link — I hadn’t seen that SCM before.

      Kalid — September 28, 2007 @ 9:04 am

    5. Wow.. you are a breath mint!
      A Life-saver to be exact.. I’ve been looking for something like this for day..
      Thanks!

      Skid Vis — September 28, 2007 @ 9:10 am

    6. That was very tasty. Thank you.

      Tony — September 28, 2007 @ 9:36 am

    7. Thanks guys! Not sure what’s happening with the food theme (lifesavers, tasty articles) but I’m happy to oblige :)

      (EDIT: Wow, I had been re-reading the article so many times that I forgot food items were the examples I used! They just became a series of words to me.)

      Kalid — September 28, 2007 @ 9:59 am

    8. Great Read

      Amit — September 28, 2007 @ 11:04 am

    9. Thanks Amit, glad you liked it.

      Kalid — September 28, 2007 @ 11:44 am

    10. Great article. Just curious what tool you used for diagramming.

      Kevin — September 28, 2007 @ 12:10 pm

    11. thanks for the outline. really helped me grasp the fundamentals. :)

      Mario — September 28, 2007 @ 1:24 pm

    12. I’m using svn that’s more than a year now and I love it. Thanks for that refreshing tuto, it makes its learning for the novice a real pleasure

      karim — September 28, 2007 @ 1:39 pm

    13. Nice article.

      May I ask where did you do that neat graphics?

      Thanks,

      Tiago Serafim — September 28, 2007 @ 4:05 pm

    14. Hi all, thanks for the comments. Ack, you want to know the secret sauce? Microsoft Paint.

      Just kidding :) . I make the diagrams in PowerPoint 2007, by drawing various shapes, arranging and styling them appropriately. If you like, check out this article:

      http://betterexplained.com/articles/an-intuitive-guide-to-exponential-functions-e/

      and the corresponding PowerPoint file:

      http://betterexplained.com/examples/graphics/Exponential-growth.pptx

      Kalid — September 28, 2007 @ 7:35 pm

    15. yes, I’ve the same question (that caused a-ha moment ) what tool do you use to make such a nice web2.0ish graphics ?

      Thanks
      Kalyan

      Kayan — September 28, 2007 @ 7:43 pm

    16. fabulous read, Thanks tons for putting this together

      venki — September 28, 2007 @ 9:07 pm

    17. @Kalyan: I used PowerPoint 2007 — there’s more details in comment #14, above.

      @venki: Thanks for the comment, it was a lot of fun to write.

      Kalid — September 28, 2007 @ 10:16 pm

    18. Great post! Thanks for doing this.

      Sam Jones — September 29, 2007 @ 7:21 am

    19. Thanks Sam, you’re more than welcome.

      Kalid — September 29, 2007 @ 9:29 am

    20. Thank you for your wonderful effort.

      Ed — September 29, 2007 @ 9:36 am

    21. Hi Ed, thanks for the support.

      Kalid — September 29, 2007 @ 9:53 am

    22. Is there a VCS that doesn’t require a server environment? Something that I can use with Visual Studio 2005 for C#

      Carlo — September 29, 2007 @ 2:50 pm

    23. Great detail of how the version control works. Thanks for time to put this together.

      brian — September 29, 2007 @ 6:35 pm

    24. Great article!
      I’d like to add my grain of salt here. If you read this and you thought “oh well, a version control system is probably hard to install” (with the server, etc.).
      I strongly suggest you try Mercurial (www.selenic.com/mercurial) or Bazaar (bazaar-vcs.org).
      You can initiate a repository in any directory with one command. No fuss. You’re then ready to commit, undo at will, as explained in the article.
      On the other hand if you ever need to setup a main server you can too. The point I want to get across is simply that using a “distributed” VCS nullifies the barrier to entry. Want a repo, anywhere? Type ‘bzr init’ or ‘hg init’. Done!

      webmat — September 29, 2007 @ 8:03 pm

    25. Oh, and Carlo, I think both my suggestions will satisfy your need. I currently work with Bazaar at work when working on my code, and I use VS2005 with C#.
      If you want a graphical user interface you might want to check for TortoiseBzr, which is a graphical front-end for Bazaar. http://bazaar-vcs.org/TortoiseBzr
      I haven’t had the time to use it yet, though.

      webmat — September 29, 2007 @ 8:09 pm

    26. @Brian: Thanks, glad you liked it!

      @webmat: Great tips, thanks for sharing! (This is exactly what I hoped would happen — people sharing their personal tips, tricks and favorites).

      @Carlo: Try out webmat’s suggestions. I know Visual Studio has plugins for various VCS systems like SVN, they may have Bazaar or Mercurial as well. This makes it easy to see the status of the project you are working on, inside of Visual Studio.

      Kalid — September 29, 2007 @ 10:17 pm

    27. While this looks like a nice introduction to the CVS and SVN model of version control, it’s pretty specific to this model.

      The “All version control systems involve the following concepts” part is certainly false unless you exclude distributed version control, systems that don’t directly track files (eg Git), systems that don’t use revisions (eg Darcs), and probably other categories.

      Anonymous — September 30, 2007 @ 12:05 am

    28. Hi, thanks for the feedback. Yes, this guide was meant to give an intro to the most common VCS concepts. I wasn’t that familiar with distributed and other systems, but it seems they can have different behavior — I may do a follow up on them. Till then, I’ll caveat the sentence with “Most” vs “All” :) .

      Kalid — September 30, 2007 @ 8:30 am

    29. Thanks this is great for non tech folk

      Gareth — October 1, 2007 @ 1:08 am

    30. Hi,
      Its awesome, I have already recommended to all newbies around me to refer it.
      good stuff. How about writing same thing for a distributed version control.

      dextrous — October 1, 2007 @ 3:01 am

    31. thanks for this great tutorial. Makes a lot of sense really quick.

      shawn — October 1, 2007 @ 10:54 am

    32. Gareth and shawn, thanks for the comments. I’m thrilled when concepts can shine through, I really believe any subject should be made sensible to everyone :)

      Dextrous, I don’t know much about distributed version control systems, but am excited to learn about them. I’d love to write more once I figure them out.

      Kalid — October 1, 2007 @ 2:51 pm

    33. very well explained indeed !!!!

      Sagar Mehta — October 2, 2007 @ 12:11 am

    34. Thanks Sagar, glad it was useful for you.

      Kalid — October 2, 2007 @ 8:55 am

    35. The content is good, but I was more impressed with the simplicity with which it is presented …

      A lot to learn for potential tutorial writers :)

      Sagar Mehta — October 4, 2007 @ 3:28 pm

    36. Thanks Sagar — I find it helps to relate new material to what people already know (like versioning their files by changing the filename). Eventually I’d like to do a tutorial on how to do a tutorial :)

      Kalid — October 4, 2007 @ 6:30 pm

    37. thank you for the article! I’ve used CVS for 2 years, but I’ve got clear understanding of branches and merging only now

      Tanya — October 21, 2007 @ 7:12 pm

    38. Great Tanya, I’m glad you found it useful!

      Kalid — October 21, 2007 @ 9:24 pm

    39. Kalid, very good intro article. I wrote “Get up and running with TortoiseSVN and Subversion in 15 minutes” a while back which will be of interest to folks starting out with SubVersion. You can find at: http://blog.surfulater.com/2007/02/28/get-up-and-running-with-tortoisesvn-and-subversion-in-15-minutes/

      Neville Franks — October 22, 2007 @ 12:04 am

    40. Hi Neville, thanks for dropping by. This article was about the high level concepts, so it’s nice to learn how to set up the nitty-gritty :)

      Kalid — October 22, 2007 @ 1:21 am

    41. Found this article while hunting for a useable distinction between Document Version and Document Revision. Any takers out there?

      Paul Ziakin — December 14, 2007 @ 3:05 pm

    42. Hi Paul, unfortunately the words “version” and “revision” seem to be used interchangibly in the sources I’ve found. It might depend on the particular version/revision control tool you are using :) .

      Kalid — December 17, 2007 @ 2:15 pm

    43. Great post! Using straight to the point explanations, attractive visual aids, and command-line examples really helped make the fundamentals easy to understand!

      Great work!

      Dan — January 25, 2008 @ 7:20 am

    44. Thanks Dan! I try to use as many techniques as I can (diagrams, text, etc.) since people learn differently. Glad it worked for you!

      Kalid — January 25, 2008 @ 10:47 am

    45. Thanks man, this is an excellent primer, just what I needed !

      Ferdinand — February 17, 2008 @ 8:28 am

    46. Thanks Ferdinand, glad it worked for you.

      Kalid — February 17, 2008 @ 11:32 am

    47. please, if possible, add a visual guide (picture/diagram) for concept of conflict.

      user — March 25, 2008 @ 12:47 am

    48. Great article!

      Being a user of CVS and SVN for years, I always have some difficulties trying to explain it to my collegues and friends, it will help me a lot!

      May I translate it into french and publish it on my weblog, with a link to your original?

      Nicolas Hoizey — March 31, 2008 @ 1:13 am

    49. Hi Nicolas, thanks for the comment, glad you enjoyed it. Sure, you can translate it, thanks for asking.

      Kalid — March 31, 2008 @ 11:19 am

    50. well explained, i like the use of diagrams. The presentation also looks very professional, thanks!

      MB — April 28, 2008 @ 6:26 pm

    51. Thanks MB!

      Kalid — April 28, 2008 @ 6:55 pm

    52. *T*H*A*N*K*S*
      :-)

      Dave — April 29, 2008 @ 5:54 am

    53. Hi Dave, you’re welcome :) .

      Kalid — April 29, 2008 @ 10:36 am

    54. Yeah, guys! CVS is a very useful tool for any of you who works with a single file during a long time while “building” its definitive content.

      However, CVS has the inconvenient of expecting to be you (the user) the one who carries out the check-in and check-out operations.

      I have found a very important tool name Live!Doc Personal Edition (www.mylivedocuments.net) which automatically carries out check-in operations and transparently keeps all the changes done in any of your files.

      I suggest you to test it …

      FHierro — May 17, 2008 @ 9:15 am

    55. amazing read! great job!

      Ambar — May 30, 2008 @ 9:46 am

    56. Thanks Ambar, glad you liked it!

      Kalid — May 30, 2008 @ 10:04 am

    57. THE BEST GUIDE FOR VCS I’ve seen.. Great great stuff…. thanks a billion

      Dilan — June 5, 2008 @ 9:43 pm

    58. Thanks Dilan, you’re welcome!

      Kalid — June 5, 2008 @ 10:58 pm

    59. What a nice paper!

      ggyy_sun — June 9, 2008 @ 11:21 pm

    60. Thanks, glad you enjoyed it.

      Kalid — June 10, 2008 @ 11:11 am

    61. Great article, really good for a version control newbie like myself.

      Bedrich — June 10, 2008 @ 1:31 pm

    62. Thanks Bedrich, glad it was helpful.

      Kalid — June 11, 2008 @ 2:01 am

    63. Excellent job! One suggestion though …

      I’ve always used a visual diff program so I was confused for a while on your explanation of the diff process. I think it would help if you pointed out that diffing r6 with r7 would generate:

      +rice
      -bread

      That is, the diff things you deliberately removed bread. How could it know the difference?

      So, when we’re ready to merge we want to know the difference between the file we started with on our branch and the final version on our branch. Then we merge those differences with the latest version on the trunk.

      Something like that. A bit more “theory” of what we’re trying to do.

      This really helped me solidify the process in my head. Thanks,

      Peace,

      Rob:-]

      Rob — July 2, 2008 @ 10:53 am

    64. “Who would have thought a version control system would be Web 2.0 compliant? Many systems let you tag (label) any revision for easy reference”

      Please, this is not remotely like folksonomic tagging in the Web 2.0 sense. If this is a joke, it’s going to confuse the heck out of people who’ve not encountered version control before.

      Tim — August 31, 2008 @ 1:33 am

    65. This is a great introduction to VCS! Source code management can be so complicated to explain, but you have made it quite clear.

      I would like to see a similar explanation of “distributed” VCS systems. I have read about them, but I have not been able to make any sense of them — they seem like trying to play volleyball when every player has her own ball. I don’t see how it can possibly be anything other than a cluster-you-know-what. But they obviously work for some projects, and I would really like that explained.

      Scartaris — September 5, 2008 @ 8:27 pm

    66. Oh! There is a link to an explanation of “distributed” version control right at the end! Thanks!

      Scartaris — September 5, 2008 @ 8:33 pm

    RSS feed for comments on this post. TrackBack URI

    Leave a comment

    Have a question? Know an explanation that caused your own a-ha moment? Write about it here.



    Subscribe (RSS or Email)
    Get new articles by email:

    Like it? Try All articles, RSS Feed or Email Subscription | Idea or suggestion? Contact me
    copyright © 2007 Kalid Azad