IntroductionPreparing to Use the CS61B ServerSubversion from the command lineSetting up a working directoryStarting a projectThe typical work cycleComparingRetrieving previous versionsURLs and pathsMergingQuick guideUNIVERSITY OF CALIFORNIADepartment of Electrical Engineeringand Computer SciencesComputer Science DivisionCS 61B P. N. HilfingerFall 2009Using Subversion1 IntroductionA version-control system (also source-code control system or revision-control system) is a utility forkeeping around multiple versions of files that are un dergoing development. Basically, it maintainscopies of as many old and current versions of the files as desired, allowing its users to retrieve oldversions (for example, to “back out” of some change they come to r egret), to compare versions of afile, to merge changes from independently changing versions of a file, to attach additional information(change logs, for example) to each version, and to defin e symbolic labels for versions to facilitate laterreference. No serious professional programmer should work without version control of some kind.Subversion, which we’ll be usin g this semester, is an open-source version-control system thatenjoys considerable use. The basic idea is simple: Subversion maintains repositories, each of whichis a set of versions (p lus a little global data). A version is simply a snapsh ot of the contents of anentire directory structure—a hierarchical collection of directories (or “folders” in the Mac and PCworlds) that contain files and other directories. A repository’s administrator (in this class, that’s thestaff), can control w hich parts of the repository any given person or group has access to.At any given time, you may have checked out a copy of all or part of one of these versions into oneof your own directories (known as a working directory). You can make wh atever changes you want(without having any effect on the repository) and then create (commit or check in) a new versioncontaining modifications, additions, or deletions you’ve made in your working directory.If you are working in a team, another member might check out a completely independent copy ofthe same version you are working on, make modifications, and commit those. You may both, fromtime to time, update your working directory to contain the latest committed files, including changesfrom other team members. Should several of you have changed a particular file—you in a committedrevision, let us s ay, and others in their working copies—then the others can update their workingcopies with your chan ges, merging in any of your changes to files you’ve both modified. After theseteam members then commit the current state of their working dir ectories, all changes they’ve madewill be available to you on request. If you attempt to commit a file that someone else has modifiedand committed, then Subversion w ill require you to update your file (merging these committedchanges into it) before it will allow you to commit.In this class, I may give you various code skeletons to be filled in with your solutions. Sometimes,these skeletons may contain errors I wish to fix, or I might take pity and add a useful method or twoafter handing out the assignment. By distributing these skeletons to you in the repository, I make itpossible for you to merge my changes in the skeletons into your own work, without your having tofind our changes and apply them by hand.1Using Subversion 2Should you mess something up, all the versions you created up to that point still exist unchangedin the repository. You can simply fall back to a previous version entirely, or replace selected files froma previous version. Of course, to make use of this facility, you must check your work in frequently.Even though the abstraction that Subversion presents is that of numbered snapshots of entiredirectory trees full of files, its representation is far more efficient. It actually stores differences betweenversions, so that storing a new version that is little changed from a pr evious one adds little data tothe repository. In particular, the representation makes it particularly fast and cheap to create a newversion that contains an additional copy of an entire subdirectory (but in a different place and with adifferent name). No matter how big the subdirectory is, the repository contains only the informationof what subdirectory in what version it was copied from. As we’ll see, you can use these cheap copiesto get the effect of branching a project, and of tagging (naming) specific versions. These copies haveother uses as well. In particular, they allow you to import a set of skeleton files for an assignmentwithout significantly increasing the size of the repository.What follows is specific to this course. Subversion actually allows much more flexible use thanI illustrate here.2 Preparing to Use the CS61B ServerSubversion is an example of a client/server system. That is, r unning it requires two programs, oneof which (the server) accesses the repository and responds to requests from the other program (theclient), which is what you run. Th e client and server need not run on the same machine, allowingremote access to the repository. We have one server program, which the staff will look after, andseveral alternatives for the client program, depending on how you are working. In this document,we’ll describe the standard command-line client (called svn), which you run in a shell.The staff will maintain a Subversion repository containing subdirectories for each of you onthe instructional machines under a staff account (cs61b-ta). The Subversion server programmanipulates th is repository and runs on one of the instructional machines. You will be able to runthe Subversion client program (svn) either from your class account or remotely from any machinewhere svn is installed.3 Subversion from the command line3.1 Setting up a working directoryWith Subversion, you are almost always working on a copy of something in the repository. Onlywhen you commit your copy (usually with the command svn commit) does the repository get changed.It is impossible to emphasize this too much—failing to commit changes (either by not issuing thecommand at all or by failing to notice error messages when you do) is the root of most evil thatbefalls beginning Subversion users .In particular, a working directory is a copy of some directory in the repository. I suggest thatyou set up such a directory un der your account.
View Full Document
Unlocking...