An Overview of Subversion and Introduction to Caching

Paul Archer began the night with a solid introduction to the Subversion version control system. In addition to the main project site, he showed two other references to information on Subversion:

As a starting point, he created a repository using the command:


       svnadmin create /path/to/repos
    

This command creates a Subversion repository by setting up an appropriate directory tree and repository storage. The repository is accessed using the svn command using a URL. For local access, you can use a file:///path/to/repos or after setting up the appropriate server you can use svn:, svn+ssh:, or http: URLs.

The main portion of the presentation followed the tutorial in the book Version Control with Subversion referenced above. In addition, Paul covered some of the benefits of version control for an individual developer.

We also briefly discussed when to commit changes. There are several models used by different groups. All of which work under different circumstances. Which one you choose depends mostly on what makes you (or your company) most comfortable. In order from informal to formal:

We also discussed the concepts of tagging and branching. A tag is normally applied to mark a set of files as a point in time we might want to recreate. For example, most groups tag the code for a release, because we will want to be able to rebuild that code at some time in the future. A branch, on the other hand, is used to perform development separate from the main line of development (the trunk). Unlike most other systems, Subversion implements tags and branches in exactly the same way, using cheap copies.

Caching

After covering the basics of Subversion, Paul turned his attention to chapter 3 of the book Higher Order Perl. This chapter covers the concept of caching, which is a standard technique for speeding up pure functions. Pure functions are defined as functions whose output depends only on their inputs. Caching can also be used on functions that depend on something other than their inputs (like a database) provided the function should always return the same output for a given set of inputs.

Paul went on to talk about the Memoize module that simplifies adding caching to a Perl function. He showed how to add caching to a function with the addition of two lines of code.


      use Memoize;
      memoize 'func';
    

He finished by talking about how the ability to easily add caching changes the way you think about optimizing code.