This is a conversation that you never want to hear.
"Oh no! The frobnitz is broken!"
"But it was working last week."
"I don't know what happened - was it the changes I made to the gorblewhonker?"
"Wait, I was putting that function in the gorblewhonker. I told you after class on Thursday, remember?"
"Shoot. Do you have last week's version with the working frobnitz? What's the difference?"
"Maybe. I don't know. Does this mean we have to redo all the improvements we've made to the blooglebox since then?"
"Argh."
Source code management tools allow you to avoid these kinds of conversations.
Virtually every FOSS project uses some kind of source code management system. In this chapter, we will... FIXME AFTER OUTLINE
Have you ever seen a folder that looked something like this?
<pre>
mycode-1.py
mycode-2.py
mycode-2-with-rachel's-changes.py
mycode-working.py
mycode-LATEST.py
</pre>
If so, you use version control. According to Wikipedia <ref>http://en.wikipedia.org/wiki/Revision_control</ref> version control "is the management of changes to documents, programs, and other information stored as computer files." You may also see this referred to as revision control, a VCS (version control system), or source control. We will use these words interchangeably throughout this chapter. Software is available to make this process easier.
version control: lots of things do version control. wikipedia, for instance. word processors. they store past versions so you can change
source code management: software that does version control, manages accounts, and so on. The best SCM systems have complex tools.
Some SCMs are highly proprietary, but fortunately, the FOSS world has many excellent SCMs to choose from. Each has their strengths and weaknesses, and choosing which SCM to use for a new project is always a popular subject for debate.
You may want to start your own project someday, but right now we're more interested in working with existing projects. Which means that you need to learn the SCM system that your chosen project uses.All SCM systems have some basic ideas in common, though. Rather than train you on a particular SCM, we will cover in this chapter the general ideas that are common to all SCM systems, with examples from four popular SCM systems: Concurrent Version System (cvs), Subversion (svn), Git (git), and Mercurial (hg).
This is the first step for most people: going and getting the code from some repository somewhere. People are working on a code project, and you want to see the latest code. How do you get it?
cvs -d:pserver:anonymous@cvs.teachingopensource.org:/tutorial/helloworld checkout helloworld
svn checkout http://svn.teachingopensource.org/tutorial/helloworld/trunk helloworld
git clone git://git.teachingopensource.org/tutorial/helloworld helloworld
hg clone http://hg.teachingopensource.org/tutorial/helloworld
You may have noticed that cvs and svn use the "checkout" command, and git and hg use the "clone" command. This is an important distinction, and we'll talk about it soon. But not yet.
4.2.2. update
The crucial thing to understand about
4.2.3. commit
4.2.4. status
4.2.5. diff
4.2.6. add
Exercise 4.2.1. Find a version control system that we haven't listed, and find the equivalent commands for all of the above functions.
You may notice that some of the commands for git look very different.
There are two basic types of version control (and several choices for each type): client-server and distributed.
4.3.1. Client-server
Centralized version control tools have One Master Copy of the code somewhere in a centralized (hence the name) location. These were the first types of version control systems; all the contributors to a project would get their code from the same server. To share their changes with each other, they would check it back into the same server. This is similar to having a shared directory on your computer where people can upload and download files.
Two common centralized version control tools are cvs and subversion. Both are still used by many projects.
4.3.2. Distributed
http://en.wikipedia.org/wiki/Distributed_revision_control
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
(note: I may be mangling/oversimplifying the history of VCSes; I'd like to get someone who's actually worked on a VCS to chime in on this. --Mchua)
What happens if the central server of a VCS goes down? What happens if two developers are working side by side but don't have access to the central server (for instance, if they're offline)? How do people share code under these circumstances?
Enter distributed version control systems (DVCS). With a DVCS, developers can share code directly with each other without having to go through any particular centralized repository. In other words, each developer's repository is a separate fork (do we define this term somewhere?) of the code. With this power comes complexity.
Distributed version control tools can also be used in a centralized way, and often projects using a DVCS will designate one checkout as the "official" place where code changes (eventually) make their way up to. Along the way, however, they can be passed from developer to developer, branch to branch, fork to fork.
Common distributed version control systems include git, mercurial, and bazaar.
=== Choosing a version control tool =
Prefer centralized:
http://blog.ianbicking.org/distributed-vs-centralized-scm.html
Prefer distributed:
http://lwn.net/Articles/246381/
Everyone has their own opinion; every project has historical reasons for picking the VCS it did. If you do a web search for "distributed vs centralized version control" or similar, you'll see some of these dicsussions. If you're joining an existing project, use the VCS they use; if you're creating your own project, use the system you're most comfortable with. It's better to have any sort of version control than none at all, and you can always switch later (note: not sure if I actually want to put that last clause in there, since switching can be painful. Possible, though.)
=== Case study: why did large project $FOO change RCS? =
== Exercise: Downloading from a repo == Wes Dillingham has a good GIT into at
http://teachingopensource.org/index.php/RIT/Git_introduction
You can use any version control system you want for this exercise.
* Install the VCS
* Look up a "checkout." What is a checkout? What is the command for a checkout in the VCS you've chosen?
* at some point we might want to put up a textbook
exercise server - I'd like to be able to set up repos for
svn, cvs, git, bzr, mercurial, etc so students can practice
checking code out, seeing commit histories, etc.
(looking for useful references here so I don't become redundant)
* http://betterexplained.com/articles/a-visual-guide-to-version-control/ (opening example inspired by this, but it's not CC-licensed so we can't really remix it...)
* http://en.wikipedia.org/wiki/Revision_control
* http://en.wikipedia.org/wiki/List_of_revision_control_software
* http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
* http://www.gutenberg.org/files/74/74.txt (used in example - Tom Sawyer)
* http://code.google.com/p/gource/ -- freaking amazing, full of WIN exercises.
== Plans for moving this chapter forward ==
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.