This post originated from an RSS feed registered with Java Buzz
by Mathias Bogaert.
Original Post: What is Version Control: Diffs and Patches
Feed Title: Scuttlebutt
Feed URL: http://feeds.feedburner.com/AtlassianDeveloperBlog
Feed Description: tech gossip by mathias
Much of the blog content was written in conjunction with Steve Losh. Steve is a programmer, photographer, blues dancer and musician. Check out Steve’s projects to see some of the cool things he has worked on, or jump over to his Bitbucket account and get straight to the source. Making the Switch to Distributed Version Control Many individuals, teams, and organizations are thinking about making the switch to distributed version control systems a la Git and Mercurial (Hg). This is the first post in a series of blog entries over the next several weeks that focus on using and understanding DVCS. Let’s start off with the basics and explore what version control is in general. In this entry, we will discuss problems that any version control aims to solve, where version control came from and some of the basic concepts you’ll need to know in order to use it. A Simple Example It’s often helpful to have a concrete example when talking about editing code, so let’s use a simple personal web page: 1234567891011121314151617 <header> <h1>John Doe</h1> A Java programmer from Chicago, IL. </header><section> <h2>About John</h2> John is experienced in many areas of Java programming. </section><section> <h2>Contact Information</h2> <ul> <li>Email: john@example.com</li> <li>Phone Number: (555) 555-1024</li> </ul> </section><footer>Copyright John Smith, 2010</footer> We’ll use this simple HTML page as an example throughout this entry. Code Changes Often The code we write as programmers changes often. Bugs need to be fixed, features need to be added, and content needs to be changed. Most code is stored as plain old text files, and we change the code by editing these files. Every time we save our changes, we overwrite the old version of the file with a new one. Unfortunately, no programmer is perfect, and sometimes, we make mistakes. If you make a change to a file, save it, compile it, and find out that something went wrong, it’s often helpful to be able to go back to the old version or to get a report of what we actually changed, in order to focus on what we may have done wrong. Suppose in our example, our fictional character John wants to update his “Contact Information” header to read “John’s Contact Information”. He might edit the file so that that section reads: 1234567<section> <h1>John's Contact Information</h1> <ul> <li>Email: john@example.com</li> <li>Phone Number: (555) 555-1024</li> </ul> </section> John saves the file, reloads the page, and notices something doesn’t look quite right. How can John figure out the problem? In this simple example, it’s fairly easy to simply read the entire file and find the problem, but it can obviously get much more difficult when you’re editing many parts of a large file that all interact with each other. One of the earliest methods that is still around for comparing versions of files is a pair of utilities called “diff” and “patch”. Modern version control systems still use the concepts (and even file formats) of these tools, so let’s take a look [...]
Previous Topic
