Subversion - Ece

Subversion

From Ece

Jump to: navigation, search

Subversion, or SVN, is a system that provides version control of files, such as source code. The files and their history are stored in a common repository which all members of a team can access. Team members "checkout" private copies of the files from the repository, make changes to them, and submit the changes back into the repository. A complete history of all such revisions is maintained in the repository. Subversion client tools provide facilities to examine the differences between revisions, or to examine older, known-good release or test configuration versions of the code.

Subversion can be a useful tool for personal programming assignments, team projects in courses like Digital System Design, or senior design projects. The Getting Started section below will direct you to other wiki pages to help you get started with Subversion.

For a good and thorough reference, however, see the official online book, Version Control with Subversion.

Contents

Basic Concepts

The following is a brief discussion of some basic concepts you should understand in order to use Subversion. This is simply a distillation of the first chapter of the online Subversion book, so you might find it beneficial to read that entire chapter.

Repository

A Subversion repository is the central store in which all versioned files are kept. It contains a record of every change to the files and folders it contains. Subversion clients can connect, by various access methods, to the repository in order to read and modify its contents. A client typically retrieves a copy of the repository (or some subdirectory within the repository), modifies the local copy, and then writes, or commits those changes back to the repository.

Repositories can be configured for private, group-wide, or public access. For more information, see Subversion Repository Administration.

A nice feature of Subversion is that every time changes are committed to the repository, only those changes are stored. For example, if you checkout a file foo.c, add a single statement to it, and commit your change, the repository only needs enough extra space to store your new line; an entire copy of the file is not necessary.

As another example, copying a file or directory tree (such as for branches and tags) is a "cheap" operation, because the repository does not actually make full copies. Instead, it just records the fact that a copy was made. If changes are made to that copy, still only those changes are actually stored.

Working Copy

With a few exceptions, clients typically do not directly make changes to the repository. Instead, a client performs a checkout of the repository or a subdirectory of the repository. That is, the client retrieves a copy of the repository in order to make changes to it locally. This local copy is called the working copy.

A working copy will always contain a subdirectory called .svn/ to store information about the working copy, such as the repository the working copy belongs to, or the original state of the files before local modifications were made.

Usually, there is no tight coupling between the working copy and the repository. The repository is unaware of the working copies that have been checked out, and so dumping a working copy is as simple as deleting the entire working copy folder that contains .svn/. The exception to this is when Subversion's locking mechanism is used, since the working copy contains a lock token proving the working copy owner owns the lock.

Global Revision Number

Subversion itself maintains only a single type of version number: the global revision. The repository is treated as a whole entity, consisting of a directory tree and files. From Subversion's view, any and every change committed to the repository constitutes a change to the repository as a whole.

Such changes include:

  • A modification to the contents of a file
  • Renaming, moving, copying, or deleting a file
  • Renaming, moving, copying, or deleting a directory

Even branches and tags are mere copies, and thus fall under the latter two categories.

So, then, the only version number used by Subversion is the global revision number, which begins at 0, and is incremented with every change to the repository.

Approaches to File-Sharing

A basic problem arises in collaborative access to files: the need for more than one person to modify the same file. There are two basic approaches to this problem.

  1. Collaborators take turns modifying a file. This approach, known as lock-modify-unlock, may be unnecessarily restrictive if the collaborators want to edit different sections of the file (i.e. their modifications do not overlap). However, in the case of file types such as images, for which overlapping changes are not easily merged/resolved, this approach makes sense.
  2. Each collaborator makes a copy of the file and modifies it. When the modifications are complete, these copies must be merged back together. This approach, known as copy-modify-merge, provides the flexibility for collaborators to make non-overlapping changes concurrently. Yet, even if the changes do overlap, the collaborators work concurrently and then review conflicting changes to determine how best to merge them into one file.

The second approach is the one preferred by Subversion. Support is included for automatically merging non-conflicting changes and alerting the user to conflicting changes. Locking of files is also supported, though, and may be preferred for certain binary file types, like images.

You may find it helpful to read the Subversion book's discussion of these two approaches.

Getting Started

To use Subversion, you must be able to connect to some repository. If you or your group does not yet have a repository, then you (or a willing person in your group) must set up the repository.

Depending on your situation, you (or your group) will have to determine how you will access the repository as well.

There are multiple wiki pages that you may want to read...

SSH Clients

Yavin only supports connecting to repositories via SSH. Additionally, you will want to create your repository from the command-line on Yavin, even if you are going to connect with the GUI client TortoiseSVN. Thus, you should probably start by reading about PuTTY (for Windows) or OpenSSH (for Linux/UNIX).

Setting up a Repository

Subversion Repository Administration covers repository creation and access methods. If you are setting up your own repository or are setting one up for your group, you will need to read through this.

Connecting to a Repository

There are a few ways (and numerous variations) to set up your connection to a repository. Connecting to a Subversion Repository covers this topic, and it is tightly coupled with the information in PuTTY and OpenSSH. The person setting up the repository can refer their group-mates here.

Basic Use

Subversion Basic Use covers some of the basic tasks of Subversion using the command-line client for examples.

Branching and Tagging

Two powerful Subversion features are branches and tags. (Technically, they are the same feature exploited in two ways).

  • Branch—alternate revision tree for adding a feature in isolation from other development, or maintaining stable release code.
  • Tag—snapshopt of the repository for purposes of releases, test builds, etc.

These features are covered in Subversion Branches and Tags.

Windows Graphical Client

Windows users wanting a graphical interface for Subversion should use TortoiseSVN.

Other

A page has been started for setting up Subversion on Linux, but it is currently a stub.

Also, the robotics research group has created a movie for the Windows users, although it does differ from some of the instructions given in the above wiki pages.

See Also

External links

Tutorials

Misc

Retrieved from "http://www.ece.msstate.edu/wiki/index.php/Subversion"