Tag Archive for 'working copy'

Subversion Tip of the Week

An Apache Subversion working copy can be created quite simply by running the ‘svn checkout’ command. However, sometimes you’ll want to have more control over the contents of your working copy; for example, when you’re working on a large project and only need to checkout a single directory.

In this post, we share two ways to get greater control over your checkout commands.

1. Checkout a particular revision

By default, Subversion performs a checkout of the HEAD revision, but in some instances you may wish to checkout a previous revision, for example when you’re recovering a file or directory that has been deleted in the HEAD revision.

To specify a revision other than HEAD, add the -r switch when performing your checkout:

svn checkout (URL) -r(revision number) (Location)

In this example, we are performing a checkout of the project as it existed at revision 10.

customizing working copy

2. Performing Shallow Checkouts

A standard Subversion checkout copies the entire directory, including every folder and file. This can be too time-consuming if you’re working on a large project, or too complicated if your project contains many different branches, tags and directories. If you don’t require a copy of your entire project, a ‘shallow checkout’ restricts the depth of the checkout by preventing Subversion from descending recursively through the repository.

To perform a shallow checkout, run the ‘svn checkout’ command with one of the following switches:

  • –depth immediates: checkout the target and any of its immediate file or children. This is useful if you don’t require any of the children’s contents.

  • –depth files: checkout the target and any of its immediate file children.

  • –depth empty: checkout the target only, without any of the files or children. This is useful when you’re working with a large project, but only require the contents of a single directory.

In this example we are performing a shallow checkout on a ‘bug fix branch’ located within the branches folder, and specifying that only the immediate file children should be included (–depth files):

customizing working copy 2

Looking for a cross-platform Subversion client? Get a free trial of SmartSVN Professional at www.smartsvn.com/download

Subversion Tip of the Week

Creating a Working Copy in Apache Subversion

The first step to creating an Apache Subversion working copy on your local machine, is to create a repository. This is made easy with uberSVN, the free, open ALM platform.

Create Your Repository

1) In uberSVN, open the ‘Repositories’ tab. Click the ‘Add’ button.

2) Enter a name and location for your repo – this is the directory name for the repository, and will appear the end of the URL. Click ‘Next.’

3) Make sure the ‘Create new repository’ and ‘Create trunk, branches and tags directories’ checkboxes are ticked. Click ‘Done.’

4) uberSVN will automatically open a ‘Permissions’ tab, where you can configure your access rules. Permissions can either be controlled by uberSVN or through an external Authorization file.

Your repository is now ready! It can be accessed through the ‘Repositories’ tab. Be sure to make a note of the repository URL as you’ll be using it to create your working copy.

Entering Commands

In Apache Subversion, commands are entered via the terminal window. In Windows, this can be opened by pressing the “Windows key” and “r.” In the ‘Run’ dialog box enter “cmd” and click “Ok.” This will open the terminal window.

Checkout a Working Copy

Now it’s time to checkout a working copy. Enter the ‘svn checkout’ command followed by the URL of your repository and the location where you wish to create your working copy.

svn checkout (URL) (location)

In this example, we’re creating a working copy on the desktop, in a file called ‘Repo’:

You have now successfully created your first working copy!

Subversion Tip of the Week

Apache Subversion: Basic Workcycle

In Apache Subversion, the basic workcycle follows the ‘checkout-edit-update-commit’ format.

A ‘Checkout’ is the process of pulling all the files from your repository onto your local machine, where it becomes known as a ‘working copy.’ You can then work on these files in isolation, before sharing your work with the rest of the team by ‘committing’ back to the repository.

In this week’s tip, we’ll provide a handy introduction to this basic workcycle.

Checkout

To checkout a working copy, run the ‘svn checkout’ command, followed by the URL of your repository and the location where you wish to create the working copy.

In this example, we’re creating a working copy on the desktop, in a file called ‘Repo’:

Tip, if you’re using the free uberSVN platform, you can easily find out your repository’s URL by opening the ‘Repositories’ tab.

You can now edit the files and folders in your working copy.

Update

You may be ready to share your changes with the rest of your team, but it’s good practice to perform an SVN update first. This will pull any changes your colleagues may have already committed, into your working copy, ensuring your changes fit with the most up-to-date version of the project.

To perform an update, run the ‘svn update’ command, followed by the location of your working copy.

svn update (working copy location)

Commit

Let’s assume any changes your team committed are compatible with your changes, and go ahead with the commit. When performing a commit, you should leave a log message and include as much information as possible, as this can be an invaluable source of information if you ever need to revisit this revision. When performing a commit, the log message is entered in the “–m” format (for example, -m “added ReadMe file.”)

The commit itself is performed using the ‘svn commit’ command, followed the log message and the location of the working copy.

svn commit -m “log message” (working copy location)

In this example, we are performing a commit with the log message “added Admin Guide text.”

Need more Subversion know-how? After getting a great response from the Apache Subversion community in 2011, Subversion Live is back for 2012, bringing the Subversion community sessions covering everything from Subversion’s future, to expert-led best practices workshops, as well as the unique opportunity to meet the core Subversion committers. We’re currently running a very special early bird offer: register now using the ‘earlybird’ code to get a 25% discount (note, the early bird offer ends 10th August, so you better be quick!)

Intro to Subversion’s Working Copy

Apache Subversion (also referred to as SVN) is an open source version control system. Although it’s widely used for managing source code files, it can actually be used to manage any type of file: images, videos and Word documents can all be managed with Subversion. At its core, Subversion allows teams to manage and coordinate the changes being made to a collection of files.

Subversion consists of two major elements. The first is the repository, which is a server where all your files are stored. The most recent revision of the repository is called the Head, although you can access previous versions from the repository. The second element, is the working copy, which we will explore in-depth in this post.

The Working Copy

‘Working copy’ is a term that’s thrown around a lot in Subversion tutorials and guidelines – but what exactly is the working copy, and how does it work? Essentially, a Subversion working copy is a directory tree on a local system that looks like any other ordinary directory full of files, but it provides a developer with their own private work area, complete with copies of the files contained within the repository. Subversion waits for instructions before making your working copy changes public, or incorporating other people’s changes into your workspace. When you’re ready to perform either of these actions, Subversion has the following commands:

  • svn commit – sends changes from your working copy to the repository. Log messages can be added with either the –file or –message switch.
  • svn update – updates your working copy with changes from the repository. The –revision switch can be used to provide a revision, or a range of revisions, to be updated to. If no revision is specified, this command brings your working copy into line with the HEAD (i.e the latest) revision.

The working copy contains all the files that have been checked out from the Subversion repository, but it also contains some additional files generated by Subversion to help maintain the working copy. One of these additional files, is a ‘.svn subdirectory’ which serves as the working copy’s administrative directory, and helps Subversion distinguish which of the versioned files contain unpublished changes, and which files are out of sync with the repository.

If you’ve been using previous versions of Subversion, you’ll notice that the .svn subdirectory underwent a major change in Subversion 1.7. In 1.7, the working copy metadata is stored in a single location, with just one .svn directory in the root of the working copy. Previously, Subversion maintained a .svn directory in every versioned directory of the working copy.

Things to Watch out For

The .svn folders are critical to Subversion’s smooth running. Typically, the best cause of action is to leave them alone, but there are several issues worth bearing in mind, to avoid disrupting these hidden folders:

  • Do not delete! – the .svn file contains the metadata that links the parent folder with the repository, so if you delete .svn, your working copy will be unable to communicate with the repository – Subversion will stop working completely!
  • No nesting – do not try to nest one working copy inside another working copy (regardless of whether the working copies have been checked out from the same repository, or different repositories.) Nesting will confuse the .svn folders, and it is likely they will be unable to communicate with any of the corresponding repositories.
  • Watch out for hidden .svn folders – make sure that when you are adding a folder to your working copy, it doesn’t contain a hidden .svn folder. If you try to copy a folder into a working copy that already contains a .svn folder, you will just get an error. If you really need to add the folder, you must first delete all the extra .svn folders.