# A Visual Guide to Version Control

Get the Math, Better Explained eBook and turn Huh? to Aha!

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

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

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

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:

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:

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:

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:

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

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:

• 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:

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” to bring the latest changes from Main into your branch:

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.

## Other Posts In This Series

Kalid Azad loves sharing Aha! moments. BetterExplained is dedicated to learning with intuition, not memorization, and is honored to serve 250k readers monthly.

Math, Better Explained is a highly-regarded Amazon bestseller. This 12-part book explains math essentials in a friendly, intuitive manner.

"If 6 stars were an option I'd give 6 stars." -- read more reviews

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

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.

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

5. Tony says:

That was very tasty. Thank you.

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

8. Thanks Amit, glad you liked it.

9. Kevin says:

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

10. thanks for the outline. really helped me grasp the fundamentals.

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

12. Tiago Serafim says:

Nice article.

May I ask where did you do that neat graphics?

Thanks,

13. Kayan says:

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

14. venki says:

fabulous read, Thanks tons for putting this together

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

16. Great post! Thanks for doing this.

17. Kalid says:

Thanks Sam, you’re more than welcome.

18. Ed says:

Thank you for your wonderful effort.

19. Kalid says:

Hi Ed, thanks for the support.

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

21. brian says:

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

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

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

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

25. Anonymous says:

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.

26. Kalid says:

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

27. Gareth says:

Thanks this is great for non tech folk

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

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

30. Kalid says:

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.

31. Sagar Mehta says:

very well explained indeed !!!!

32. Kalid says:

Thanks Sagar, glad it was useful for you.

33. Sagar Mehta says:

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

34. Kalid says:

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

35. Tanya says:

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

36. Kalid says:

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

37. Kalid says:

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

38. Paul Ziakin says:

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

39. Kalid says:

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

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

41. Kalid says:

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

42. Ferdinand says:

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

43. Thanks Ferdinand, glad it worked for you.

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

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

46. Kalid says:

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

47. MB says:

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

48. Kalid says:

Thanks MB!

49. Dave says:

*T*H*A*N*K*S*

50. Kalid says:

Hi Dave, you’re welcome :).

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

52. Ambar says:

53. Kalid says:

Thanks Ambar, glad you liked it!

54. Dilan says:

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

55. Kalid says:

Thanks Dilan, you’re welcome!

56. ggyy_sun says:

What a nice paper!

57. Kalid says:

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

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

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

61. Tim says:

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

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

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

64. Ammar says:

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!

65. Kalid says:

@Scartaris: No problem, glad you found it.

66. Jeff says:

Thank you! This is good stuff. -j

67. Rythums says:

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 }$

ryth

68. Kalid says:

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

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

70. Manish says:

It is such a treat to read a documents like this. Kalid, you rock!!

71. @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!

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

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?

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

75. Walter says:

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.

76. @Walter: You’re welcome — hope it works out for you!

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!

78. Shyam says:

Good article

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

80. @webCV: You’re welcome!

81. Ranu Mandan says:

that was the most simplest of all
thx for sharing

82. @Ranu: Thanks!

83. Ramesh says:

Thanks very much for sharing. I have been looking for an article like this

84. @Ramesh: You’re welcome!

85. Niks says:

Kalid,
Can I reuse the pictures (copy) to our folks in a PPT or something??

86. @Niks: Sure thing, but please include a reference back to the site. Thanks!

87. Kavin says:

Sir, it was very useful to know the basics of how one of the largest software projects is organized.

88. Kalid says:

89. skmwenda says:

Great stuff!now i fully get branching, and when to use RI or FI.

90. Kalid says:

91. Awesome post….
Really nice and easy to learn Source Control Concepts from the scratch
LOve U buddy

92. Kalid says:

@S M, @Deependra : Glad you liked it!

93. joy says:

Excellent! Thank you!

94. Kalid says:

@joy: You’re welcome!

95. Km says:

Lovely guide. No prob in understanding at all.

96. thanks for the post, its really helpful

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

98. Amazingly well explained. I’m sending this to the non softare guys at work

99. sujith says:

Woderful !! thank You !!!

100. says:

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!

101. Kalid says:

@淼: Yoiu’re welcome, glad it helped!

102. Bernard says:

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

103. Kalid says:

@Bernard: Thanks!

104. Rob Langley says:

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

105. Kalid says:

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

106. Great high-level SVN overview. Love the visuals!

107. Appan says:

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

108. @Appan: Thanks, glad you liked it! Yep, this was just a personal post, not part of an organization.

109. Raj says:

Its cool, i have read some part and seems good

110. m4niac says:

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.

111. michael kenner says:

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

112. Kalid says:

@Michael: Thank you, glad it helped!

113. ss says:

good article

114. Anonymous says:

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

115. Kalid says:

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

116. Aya says:

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

117. LOL looking at the words like, blamestorming and monkeying.Absolutely loved it.

118. sakhunzai says:

simply superb !

119. Anonymous says:

thanks a lot for this work, we will wait many from u

120. Anonymous says:

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.

121. Kalid says:

@Anonymous: You’re welcome!

122. Kalid says:

@Catherine: Thanks, glad you liked it.

123. Jorge Contreras says:

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!

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

125. Kalid says:

@Pawankumar: Thanks!

126. Michelle says:

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

127. Kalid says:

@Michelle: Thanks!

128. ow, this article really gives me a fantastic idea of what version control is a

129. betterexplained.com has been helping me and my college friends with our school projects.

130. Pretty kewl. Stands up to the name- BetterExplained

131. Kalid says:

@Mohnish: Thanks :).

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

133. Kalid says:

@Denim Geek: Appreciate the comment!

134. rosy says:

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

135. raj says:

good stuff mate..!!!!

136. Michael says:

What a great resource, and so well written. Thanks Kalid.

137. Kalid says:

@Michael: Thank you!

138. Khaled says:

Thanks man, it was very helpfull…

139. Kalid says:

@Khaled: You’re welcome!

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

141. Saleh says:

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

142. Kalid says:

@Saleh: Glad you liked it! :). Yep, there are GUI tools for SVN like TortoiseSVN.

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

144. kalid says:

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

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

146. kalid says:

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

147. Amit says:

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…

148. Hemang says:

Great work ! Thanks a lot !

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

150. kalid says:

@Hemang: You’re welcome!

151. kalid says:

@Amit: Thank you, glad it helped!

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

153. kalid says:

@Karen: Thank you!

154. Pretty great post. I just stumbled upon your weblog and wished to mention that I have truly loved browsing your blog posts. After all I will be subscribing to your rss feed and I hope you write again soon!

155. You are simply awesome…great article….explained everything.

156. kalid says:

157. Vijayakumar says:

Thanks for this wonderful work.

158. kalid says:

159. Papoj says:

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!

160. Emilio says:

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.

161. kalid says:

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

162. Deepak says:

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

163. kalid says:

@Deepak: Thanks!

164. Emilio says:

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.

165. kalid says:

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

166. ANdrew says:

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!

167. Stephen says:

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

168. kalid says:

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

169. Just wanted to point out that if you are on Windows, the new GitExtension package includes everything you will need to setup msysGit and the configuration works with TortoiseGit too. May save you some time.

170. brighteyes27 says:

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!

171. kalid says:

172. Robbie says:

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

173. Jommar says:

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

174. kalid says:

175. ann says:

Very good explanation. Thanks

176. Kaviraj R says:

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.

177. kalid says:

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

178. Vee says:

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

Thanks

179. Bunnynew says:

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.

180. 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! Your article is fantastic great!

181. kalid says:

Thanks Denys!

182. 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: Error parsing arguments

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

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

184. kalid says:

Hi Shashank, thanks for the kind words — really glad it helped!

185. Gene Ricky Shaw says:

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.

I’ve learned a lot bro… thumbs up for this nice article

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

188. kalid says:

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.

189. Great intro to source control, Kalid. I’ve been looking for a good explanation somewhere online to send folks – cheers!

190. Ashish says:

it was great explanation can you provide me any of your website address or forum where i can find more relevant other topics of networking/linux/windows etc.. it will be very helpful ….

finally thank you so much for this simple and clear explanation…

191. Graham Millward says:

That was just a brilliant piece of training material. I thought I was new to version control, but as you quite rightly point out we all use “save as” commands to record our latest version. Applying for a job where version control for ordinary word and excel files will by my main responsibility. Collaboration of the workforce will be the most difficult objective in creating good habits. People are very touchy about other people editing their work.

192. kalid says:

Thanks Graham — I like finding ways to relate new tools to the workflows we’re already using. Often there’s an overlap to build from. And yep, the social elements of these tools is usually more complex than the technical ones :).

193. ashwyn says:

You rock man !!
This is really great.
Thanks a lot.

194. Thank you for the article (assigned reading for a course preparing CS169X T.A.’s on edX).

As is the responsible thing to do when typos are encountered: please note that the sentence “Later, you “Forward Integrate” and to get the latest changes from Main into your branch:” contains a typo and should probably read something like “Later, you “Forward Integrate” to get the latest changes from Main into your branch:” or “Later, to get the latest changes from Main into your branch, you “Forward Integrate””.

195. kalid says:

Thanks Rishi, I just updated the article!

196. Anonymous says:

this guide is clear and easy to follow , thank you very much!

197. Hassn Shokri says:

Hi Kalid
But I get a little confused when you said:
“If we diffed r6 and r7, we would lose the “Bread” feature that was in main”

But I think different:
r6:
Milk
Eggs
Soup
Rice
r7:
Milk
Eggs
Soup

So the diff r6:7 is:
-Rice

And if we merge the diff we would lost the “Rice” not the “Bread”.
Am I think correctly?

198. Very nice presentation khalid ..thanks a ton to u .. am keeping my very basic steps to kind of programming and for any programming VCS is required and to use to that i learnt ABCD from your article ..excellent

199. Anjaneyulu says:

This is Clear very clear explanation…thank u so much