|Download, Select Code To D/L
(Suggested title: Using Subversion for revision control) (unfinished)
This node seeks to provide a logical and conceptual homologue of a similarly-titled node. This node is perhaps not as timely as it could have been had I posted it around the time that I started it, but several Real Life tm things have gotten in the way and I'm only now making a return to PerlMonks. However, I do hope that it has some use for people not yet familiar with SVN.
This node targets the following groups (though others may gain something from it as well):
- Developers who are displeased with any shortcomings of CVS
- Developers who choose not to or cannot use CVS because of its license
- Developers new to revision control systems (hereinafter RCS) or source control managers (hereinafter SCM)
- Developers who would like to be able to exploit the abilities of Perl while managing their repositories
What does this node cover?
This node provides all of the information for a developer to start utilising an already setup SVN system to manage their files. I will discuss at some length the following concepts and procedures:
- Creating a repository into which one can import their files
- The proper organisational structure of an SVN repository and why one should adhere to this structure
- The initial import of files into a repository
- Checking out the recently imported files to create a working copy of the repository
- How to -- and more importantly, how not to -- manage one's working copy.
What does this node not cover?
There are a few issues which this node cannot feasibly cover without becoming too large, and too mired in details. The most significant of these is that I cannot possibly cover all of the possible ways to install and configure SVN. In trying to keep this tutorial as platform-independent as possible, I cannot faithfully detail the myriad possibilities of SVN configurations without certainly missing a popular configuration. In addition to setup and configuration issues, this tutorial sticks to the basics. Thus, I won't be covering the SVN Perl API as I haven't yet found a way to employ it on Windows systems. I will gladly add information on using the SVN Perl API on Windows, if someone provides me with such. Another important facet of development with SVN that will be missing from this tutorial is the concept of hooks, which allow you to execute programs when certain actions occur (e.g. running a shell script when someone makes a commit).
Why use revision control?
To echo the advice given here: because you should. But, as I'm quite fond of saying, because isn't a reason, and neither is because you should. Thus, here are some real reasons to use an RCS:
- RCS systems allow you to keep track of your progress. If something breaks, you can easily backtrack and determine the precise revision which introduced the problem, and from there fix said problem.
- Any decent RCS system imposes the requirement for users to comment on any change made to files in the repository. This allows developers to obtain, at a glance, a summary of the work on selected files.
- RCS systems log every change made to every file (and some log changes to directories, like SVN). Because of this, they can give you any version of any file that ever existed in the repository. They can also provide you with diff(1) output between any two revisions or between the states of a file at any two points in time.
- Quality RCS systems support the concept of branches. A branch is a logical or conceptual path of development which is separate from the main path, referred to as the trunk. It helps to think of the entire structure as a tree, with the main development occurring in the trunk and different concepts / philosophies being explored in branches. More on this later.
- Another important facet of RCS systems is that they not only log what has changed in files over time, but also who made those changes, and when they made them. Having this knowledge is paramount in a group environment for managing accountability -- both in the negative and positive aspects.
Why Subversion? Doesn't "subversion" have a meaning similar to "sabotage"?
SVN offers a number of things beyond CVS. I'll leave it up to the developer to decide whether they want to use SVN. And yes, the name has a meaning similar to "sabotage". My only idea on this is that it's not so much subversion as sub version, i.e., a sub version, like version 2.5.4 of a program, where 5 is the sub version.
Enough prattling; how about actually getting some useful work done?
Creating a Repository
You create a repository with SVN using the svnadmin tool. Its syntax is available upon request with the svnadmin help command. As you can see, the programs of SVN work very similar to those of CVS: the program name is given, then a general action is specified, followed by command line options and arguments for the action.
All that's well and good. But it's not actually getting us anywhere. You need a directory name in your filesystem under which your repository will live. In these examples, we'll use /usr/home/user/repo as the top-level directory of the repository. Feel free to substitute something more appropriate for your configuration. So, let's get started (finally). To do this, we use the svnadmin create command, like so:
svnadmin create /usr/home/user/repo
Assuming you have write permission to the directory in question, the files written by the process won't cause any quota problems, and you generally don't reach any system limits, you should have a freshly-minted SVN repository at the given directory. Let's take a look, shall we?
$ ls /usr/home/user/repo README.txt conf dav db format + hooks locks $