Download Version Control with Subversion-Software Engineering-Lab Manual and more Lecture notes Software Engineering in PDF only on Docsity!
Software Engineering Lab
Version Control with Subversion
What is Subversion?
Subversion is a free/open source version control system. That is, Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of ātime machine.ā Subversion can operate across networks, which allows it to be used by people on different computers. At some level, the ability for various people to modify and manage the same set of data from their respective locations fosters collaboration. Progress can occur more quickly without a single conduit through which all modifications must occur. And because the work is versioned, you need not fear that quality is the tradeāoff for losing that conduitāif some incorrect change is made to the data, just undo that change.
Some version control systems are also software configuration management (SCM) systems. These systems are specifically tailored to manage trees of source code and have many features that are specific to software developmentāsuch as natively understanding programming languages, or supplying tools for building software. Subversion, however, is not one of these systems. It is a general system that can be used to manage any collection of files. For you, those files might be source codeāfor others, anything from grocery shopping lists to digital video mix downs and beyond.
Fundamental Concepts
The Repository
Subversion is a centralized system for sharing information. At its core is a repository, which is a central store of data. The repository stores information in the form of a file system treeāa typical hierarchy of files and directories. A number of clients connect to the repository, and then read or write to these files. By writing data, a client makes the information available to others; by reading data, the client receives information from others. So why is this interesting? So far, this sounds like the definition of a typical file server. And indeed, the repository is a kind of file server, but it's not your usual breed. What makes the Subversion repository special is that it remembers every change ever written to itāevery change to every file, and even changes to the directory tree itself, such as the addition, deletion, and rearrangement of files and
directories. When a client reads data from the repository, it normally sees only the latest version of the file system tree. But the client also has the ability to view previous states of the file system. For example, a client can ask historical questions such as āWhat did this directory contain last Wednesday?ā and āWho was the last person to change this file, and what changes did he make?ā These are the sorts of questions that are at the heart of any version control system: systems that are designed to track changes to data over time.
Task 1: Setting up your Repository on Google Project
Step 1a. Google Account
- Login used for all Google services like Gmail, Blogger, etc.
- Go to (https://www.google.com/accounts/NewAccount) and create an account
Step 1b. Software Project
- Go to http://code.google.com/hosting/ and click ā create new a project ā and fill out the form.
Step 1c. GoogleCode.com Password
- Sign in to Project Hosting
- Go to Profile >> Settings
- Take note of your password (better to save in notepad file)
Enter project name and other information
Select Version control system i.e. Subversion
Select Source code license i.e. GNU GPL v
Task 3: Preparing your Data and Folder Structure to Publish to
Repository
Step 3a. Create Folder Structure
- Open up Windows Explorer and create a new folder āLab1ā, inside which create 2 more folders ācalcā and āpaintā. Create some dummy files (shown in the file hierarchy tree (figure right)) and place them in the calc and paint folders.
Step 3b. Import your newly created Lab1 structure into the Repository
- Navigate to the folder inside which you created the Lab1 folder
- Type the following import command (but using your own repository name, username and password)
c:>svn import Lab1 https://softwareengineeringdemo.googlecode.com/svn/trunk/ -- username [email protected] -m "initial import" --config-option servers:global:http-proxy-host=10.3.20.10 --config-option servers:global:http- proxy-port=
Authentication realm: <https://softwareengineeringdemo.googlecode.com:
Google Code Subversion Repository Password for '[email protected]': ************ Adding Lab1\calc Adding Lab1\calc\makefile.txt Adding Lab1\calc\button.c Adding Lab1\calc\integer.c
Adding Lab1\paint Adding Lab1\paint\brush.c Adding Lab1\paint\makefile.txt Adding Lab1\paint\canvas.c
Committed revision 2.
Administrative Directory
A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, each directory in your working copy contains a subdirectory named .svn, also known as the working copy's administrative directory. The files in each administrative directory help Subversion recognize which files contain unpublished changes, and which files are out of date with respect to others' work.
Task 4: The checkout Command: Restoring (checking out) an Existing
Working Copy from the Repository
For example, suppose you have a repository that contains two software projects, paint and calc. Each project lives in its own topālevel subdirectory, To get a working copy, you must check out some subtree of the repository. (The term check out may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you.) For example, if you check out /calc, you will get a working copy like this:
Step 4a. Execute the following command inside your āMy Documentsā folder
C:\ >svn checkout https://softwareengineeringdemo.googlecode.com/svn/trunk/calc -- username [email protected] --config-option servers:global:http-proxy- host=10.3.20.10 --config-option servers:global:http-proxy-port=
A calc\makefile.txt A calc\button.c A calc\integer.c Checked out revision 2.
The list of letter As in the left margin indicates that Subversion is adding a number of items to your working copy. You now have a personal copy of the repository's /calc directory, with one additional entryā.svnāwhich holds the extra information needed by Subversion, as mentioned earlier.
Task 5: Committing or Checking-In: Publishing changes made in the
Working Copy to the Repository
Suppose you make changes to button.c. Since the .svn directory remembers the file's original modification date and contents, Subversion can tell that you've changed the file. However, Subversion does not make your changes public until you explicitly tell it to. The act of publishing your changes is more commonly known as committing (or checking in ) changes to the repository. To publish your changes to others, you can use Subversion's svn commit command: Step 5a. Change the contents of button.c file from āThis is my button code.ā To āThis is my new and improved button codeā
Step 5b Execute the following command inside your ācalcā folder
C:>svn commit button.c -m "Fixed a typo in button.c" --config-option servers:global:httpproxy-host=10.3.20.10 --config-option servers:global:http- proxy-port=
Authentication realm: <https://softwareengineeringdemo.googlecode.com:
Google Code Subversion Repository Username: [email protected] Password for '[email protected]': ************ Sending button.c Transmitting file data Committed revision 3.
Task 6: Updating: Incorporating changes made to Repository by other
team-members to Working Copy
Now your changes to button.c have been committed to the repository, with a note describing your change (namely, that you fixed a typo). If another user checks out a working copy of /calc, he will see your changes in the latest version of the file. Suppose you have a collaborator, Bashira, who checked out a working copy of /calc at the same time you did. When you commit your change to button.c, Bashira's
The output from the svn update command indicates that Subversion updated the contents of button.c. Note that Bashira didn't need to specify which files to update; Subversion uses the information in the .svn directory as well as further information in the repository, to decide which files need to be brought up to date.
How SVN Helps Resolve Conflicts
The U (which stands for āUpdatedā) and G (for āmerGedā) codes are no cause for concern; those files cleanly absorbed changes from the repository. A file marked with U contains no local changes but was updated with changes from the repository.
One marked with G had local changes to begin with, but the changes coming from the repository didn't overlap with those local changes.
Sometimes there is a need for interactive conflict resolution. This means that the changes from the server overlapped with your own, and you have the opportunity to resolve this conflict. The most commonly used options are displayed, but you can see all of the options by typing h :
Let's briefly review each of these options before we go into detail on what each option means.
(p) postpone Leave the file in a conflicted state for you to resolve after your update is complete. (df) diffāfull Display the differences between the base revision and the conflicted file itself in unified diff format. (e) edit Open the file in conflict with your favorite editor, as set in the environment variable EDITOR. (r) resolved After editing a file, tell svn that you've resolved the conflicts in the file and that it should accept the current contentsā basically that you've āresolvedā the conflict. (mf) mineāfull Discard the newly received changes from the server and use only your local changes for the file under review. (tf) theirsāfull Discard your local changes to the file under review and use only the newly received changes from the server.
Step 6f Now ask bashira to commit button.c file from his PC to the repository using the commit command show in step 5b.
Revisions: An svn commit operation publishes changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents; create, delete, rename, and copy files and directories; and then commit a complete set of changes as an atomic transaction.
By atomic transaction, we mean simply this: either all of the changes happen in the repository, or none of them happens. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions. Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered 0 and consists of nothing but an empty root directory. It's important to note that working copies do not always correspond to any single revision in the repository; they may contain files from several different revisions. For example, suppose you check out a working copy from a repository whose most recent revision is 4:
calc/Makefile: integer.c: button.c:
At the moment, this working directory corresponds exactly to revision 4 in the repository. However, suppose you make a change to button.c, and commit that change. Assuming no other commits have taken place, your commit will create revision 5 of the repository, and your working copy will now look like this:
calc/Makefile: integer.c: button.c:
Suppose that, at this point, Bashira commits a change to integer.c, creating revision 6. If you use svn update to bring your working copy up to date, it will look like this:
calc/Makefile: integer.c: button.c:
