A Visual Guide to Version Control

by

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. Let’s cover the high-level concepts without getting stuck in the syntax (the Subversion 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.). In Subversion you’d do:

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.

Like these diagrams? Buy the original slides for only $5

Other Posts In This Series

  1. A Visual Guide to Version Control (This post)
  2. Intro to Distributed Version Control (Illustrated)
  3. Aha! Moments When Learning Git
Enjoying BetterExplained? Also try InstaCalc on the Mac App Store. It's the fast, easy, shareable calculator you'll love using.

Share what worked: Aha moments & FAQ

Let's create a living reference for how best to understand this topic.

342 thoughts on “A Visual Guide to Version Control”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  66. Thank you very much for this great resource – I will definitely point it to my colleagues so that they learn about source control.

    Much thanks!

  69. It was very helpful
    I have a question …
    In any of the file header say a *.c file I want to maintain the comments of commiting is it possible to do that automatically…?
    by putting a directive as \displaystyle{ svn commit } or something similar …?
    for example, have a file header as
    // file name : xxx.c
    // auther : xyz
    // creation date : dd mm yy
    // revisions : date – comment
    // 1.0 : dd-mm-yy – base version
    // 1.1 : dd-mm-yy – trying auto-version
    // : \displaystyle{ svn commit }

    thanks in advance
    ryth

  70. @Jeff: You’re welcome.

    @Rythums: Offhand, I don’t know of a simple way to prepend the comments to the file (ironically, that would make the file have a new revision, right?). In general, the source control system should probably be used to view the log/history of a file.

  71. This is fantastic. I’ve been interested in using version control at the office but I’m pretty sure our IT team thinks it’s not worth it for my needs (more along the lines of grocery lists than software development). Do you know of any program that does this sort of thing at a more basic level, for everyday users?

    Love the site, great idea.

  73. @Tracy: Thanks for the comment. Subversion is probably the simplest system to use (it has plugins like TortoiseSVN for Windows so you don’t need to use the command line).

    @Manish: Thanks!

  74. Thanks for this! I understand the topic but haven’t found a better guide yet. So many times I tried to explain the concept and haven’t succeeded in doing so. I’ll try this guide next time.

  75. This is great for the concepts – but for a newbie, i’m a little lost without an ab initio. i write web code, never use the command line, and am not sure if there is a software like subversion that is assumed to be in use?

  76. @imissmyjuno: You’re welcome!

    @brad: Thanks for the comment — I realize I forgot to mention the examples were for Subversion! (I’ll update that now). The key principles, pros and cons, and diagrams should apply to most traditional version control systems like Subversion, CVS or RCS.

  77. Kalid,

    Many thanks. I’m a small projects guy who has been wavering about using vcs for a while, and this tipped me toward using it.

  79. most appreciated. u v got a great way of explaining concepts in a simple way. Thank u a lot n i wish u a lot of luck!

    adi

  83. Excellent article! Thanks for this fantastic article which explains(better! :-) with clear diagrams, how VCS works … Done a bit of digging and SVN seems the way to go. Glad there’s a plugin for quanta plus since I use that for PHP. Again, thanks for an awesome article Kalid.

  106. That is really a good guide! Very easy to understand and helpful. I am having less fear to the version control things at least, haha. Thanks very much!

  108. I was looking for a user guide to version control. This is really an excellent introduction.

  110. hi – I know this sounds like a tall order but does anyone know of a VCS that would deal with the entire origination process, please? (ie, pulling in all sorts of different source files – text, Word, EPSs, TIFs, jpegs – then through Quark/InDesign and through to PDF)

    thanks

    Rob

  111. @Rob: I think your best bet would be to use VersionCue or some software designed just for the various Adobe formats — most generic VCS systems are optimized to working with plain text files.

  113. Very informative and detailed note on VCS.
    Is it an individual contribution or an organisations contribution ? whoever did it, thank you so much.
    Ap

  116. I’ve just started out to read the tutorial and I already want to tell you I felt in love with this whole new VCS stuff :P . Thanks for that! And of course, for this amazing tutorial.

  117. Absolutely Great. A credit to the author Kalid Azad. Very interesting and very easy to follow!

  120. wow! i have never come across any read(specially in IT) which was so easy to understahnd.
    i was LOL looking at the words like, blamestorming and monkeying.Absolutely loved it.
    It truly is “better explained”.
    keep up the good work.

    Cheers!!

  121. @Anonymous: Thanks! Yeah, there’s no reason guides have to be dull — nobody wants to read (or write) that ;) .

  122. WOW !! that was amazing and so simple indeed .. I’m a third year student in FCI and I have a presentation about VCS and I gotta tell you that ur article was more than helpful to me .. thanx alot .. great effort :)

  126. Thanks you for explaining the basic principals it makes things more clear to me and will help me in fixing the way I set my VCS up and maintain it in the future.

  130. Hey ! this is a very good article. I had tried to understand version control, I didnt know where to start, luckily I found this. It’s simple, useful. Nice job!

  131. Hi,

    It was an awesome article on Version Control System. I have an interview on monday and less time to look around, but your information made my day. Its the best article I ever saw on VCS

    Hats Off !

  133. Wow, this article really gives me a fantastic idea of what version control is all about!!Great job!

  139. I actually wrote something very similar to this for my dissertation a few years ago. Great article, well done on explaining this a lot clearer than i could :)

  141. hello people i fell really helpful with this data provided…..actually VCS is my research topic so..i was just thinking that if u could send me some more contents over VCS…it will be very very helpful to me …bdw thanx a lot kalid…:)

  147. We are a gaggle of volunteers and starting a brand new scheme in our community. Your web site provided us with valuable info to work on. You have performed an impressive task and our whole neighborhood can be grateful to you.

  148. It is definitely “Better Explained”. Now, is there a GUI instead of command line? :)
    Thanks for the beautiful explanation.

  150. Hi Kalid…An interviewer asked me this question..

    If there are 55 versions of a file available…55th one is the latest one…developer checked out the 50th version and do some modification and then check in…what will be the new version…i replied…56th…i think it was 51th…

    What would be the answer ?

    Vishnu

  151. @Vishnu: That’s a strange question, I think the interviewer may have been misinformed about how version control works. Normally you don’t ask “what is the version number” as version control takes care of that for you, and you don’t revise old versions, you only add new ones (a revised old version becomes a new element).

  152. Great article.
    I wish there were free CVS/SVN systems that actually do what they are supposed to.
    I tried 5 different “free” ones, including Tortoise which especially doesn’t work as advertised.
    Haven’t tried commercial ones yet but I bet there’s at least one worth the money.

  153. @Sole42: Thanks. Yes, some interfaces aren’t as clean/easy as others — I prefer using the command-line just because it’s consistent / “easy to use” once you’ve learned it.

  154. Thanx kalid!!!! It helped me so much to get basic ideas very easily… Nice technique to present the complex information in simple way… Simply great!!! I am beginner for Source Code Control… and hope that u help me to get myself deeper into this concept…
    thnx again… :-)

  156. Now that’s a systematic approach of doing things. Thank you for the post sir, keep posting more of your nice articles. Thanks

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

    Awesome work!

  166. Thank you for the post! It is very helpful since the beginning that you make connection with the simple idea of version control system by renaming files (so I feel familiar and ready to read what you will write later on). The visual explanation is great, and the accompanying SVN commands are even more helpful. May I ask you to add the comparison with Git as well? I am learning Git and any comparison like (commit in git = merge in svn) would be perfect. Thank you very much!

  168. kalid, what kind of license has this article? I want to translate parts of it into spanish, for educational uses (very-first course in university). I don’t need all the information here, only the big ideas, and you have one of the best explication I’ve found.

  169. @Emilio: Feel free to translate and use the article for educational use! Just please include a reference back to the original. Thanks!

  170. Hi Kalid, thatnks for this nice visual article….Now I git it :) ..keep the good work going….

  172. Kalid, Thank YOU! I will put the source. If you want, you can send an email, when the document is finished, I could send you a copy. Do you use visio for the graphics? I think I’ll use libreoffice draw.

  173. @Emilio: You’re welcome! Sure, it’d be fun to see the article when you’re done. I use Powerpoint 2007 for the graphics.

  174. Great stuff, your article explains version control very nicely!

    I like that you’ve used a combination of methods to explain the concepts, and haven’t posted large blocks of svn/git/hg commands!

  175. Thanks a lot!! I have heard about version control for ages but never really understood till I read your article!

  176. @Stephen: Awesome, glad it helped!

    @Andrew: Thanks, appreciate it. Definitely, just throwing a chunk of text commands at someone doesn’t convey the intuition behind it all.

  178. Thanks Kalid, the write-up was done well. I have a much better understanding on the Version Control concept. The visual examples were very helpful and sealed the knowledge in my brain. Thanks again!

  180. I was struggling to understand version control and then I found this and it was so clear and concise that it helped me to understand what is being stated about it.
    Thanks

  181. It helped me to understand the functionality and the usage of the VCS. Thanks

  184. Is there any standards to follow for version numbers? that is V1, V2, V3….. and V1.1 V1.2, V1.3….
    how to decide which number system to use.
    if i use v1.1,v1.2… v1.9 what is next? is there any specification to choose V1.10 or V2.0.

  185. @Kaviraj: No official standards, but it’s usually MajorVersion.MinorVersion. So if it’s a small upgrade, you only increment the minor version. v1.0 to v1.9 to v1.10 to v1.11. Note that “v1.10″ and “v1.1″ look similar, so it’s best to skip “1.10″ and go to “1.11″.

  186. A fantastic article for every type of user typically. This help out in lot of concept and situations.

    Thanks

  187. Hi,
    I recently started using Apache VisualSubversion. We are testing in Standard Free Edition. It is working nicely. My Developers want that, instead of committing in Repos directly, it should be passed via an Admin.
    To be clear, if they do any changes in source file, it should be notify to an Admin user. That admin user should be able to commit in Repos after reveiwing the changes in source file.
    Is this possible as I didnot find anything in visualsubversion ?
    Is there any other product to achieve this ?

    Thanks.

  188. The web is full of info about version control and Subversion, but was extremely hard to me to find a basic guide for starters!! Thank you a lot! :D Your article is fantastic great! :D

  190. Great guide, thanks a lot! I will reuse some parts of it in my teaching at the university.

    Here is one bug report: “svn co -r1 file” doesn’t work for me, using svn 1.7.7 on Linux:

    $ svn co -r1 file
    svn: E205000: Try ‘svn help’ for more info
    svn: E205000: Error parsing arguments

    However I do get the same effect by using “svn up -r1 file”.

  191. I’m out of words to praise the author of this article. Nothing can I do than just leaving this comment.

    The ideology of elucidating concepts with high-level examples but short sentences is awesome.. I’ve only dreamt of such lectures all my life. Thanks a lot for making my understanding of VCS good.

    Honestly I’d say this article is the first of its kind on this topic which made me feel excited throughout reading..

  194. This was a great guide! It explained not only the basics but gave fairly detailed explains of version control. Very informative, I learned a lot.

  196. Version control systems are all crap because they use a command line interface to control them. I have my own system that is totally automated and doesn’t need me to drop to a shell console and issue commands all the time.

    When version control systems get with the times and use a GUI, let me know. As of now, they’re all manual and slow crap that look like software from the 80′s. Get with the times!

  197. Hi Tim, the problem with automated systems is you want to control when things are marked as known good (usually so they’re in a consistent state). There are GUI tools for most version control systems, such as TortoiseSVN or TortoiseGit.

Your feedback is welcome -- leave a reply!

Your email address will not be published.

LaTeX: $$e=mc^2$$