1

Subversion FundamentalsSubversion Fundamentals

Quentin HartmanQuentin HartmanConcentric Sky, IncConcentric Sky, Inc

March 17th, 2009March 17th, 2009Eugene IT Pro ForumEugene IT Pro Forum

My name is Quentin Hartman and I will be giving an introduction to version control with Subversion tonight. I am a system administrator with Concentric Sky here in Eugene. We offer web development and application consulting services with with a focus on emerging technologies like social media and the iPhone.

This presentation is a reduced version of a 3 hour training seminar that I developed. The biggest difference is that I will be skipping the live demos and the in-depth tool-specific conversation. Instead I will be focusing on core concepts. My hope is that after this presentation you will have enough of a framework to dig in on your own and start realizing the benefits of using a VCS in your own projects.

2

Core ConceptsCore Concepts

Version Control Systems. Lots of different names, same basic concepts. Repositories containing a set of files, and optionally, and a set (or sets) of files which represent different branches of development or released versions of files.

Everyone agrees using a VCS of some kind is a good idea. Why?

●Track changes over time, and roll back changes if needed●Maintain old versions of code●Coordinate distributed, parallel development by many people.

● Communication!!!●Act as a simple ”just in time backup” of an individual coders' work.

Virtually all VCS systems share some common concept: repos, branches, and tags

3

ReposRepos

Essentially just a group of files that are ostensibly related to each other. Sometimes they all belong to the same project, sometimes they are worked on by the same team, sometimes they are owned by the same person or company. The logical grouping is entirely up to you.

Most people say that a repo contains at least a ”trunk”. The ”trunk” is typically the main contents of the repo. In CVS this was called ”head”, and is often considered to be the ”latest and greatest” of whatever is in the repo.

4

Branches and TagsBranches and Tags

A ”branch” is essentially a divergence of the contents of the repository. It can be a ”permanent” thing, say, a new project that is based on an existing one. Or it can be temporary, only existing long enough for some new content or feature to be developed.

A ”tag” is usually a snapshot of the ”trunk” at a certain point in time that does not change. In software development, this usually correlates to a particular release of the software.

Unlike many VCS implementations, there is nothing special about a ”branch” or a ”tag” in subversion. Any special meaning applied to those concepts is done entirely by the people working in the repository.

That means that ultimately, you can use, or not use, branches and tags however you see fit. There is no on ”right way” to do it, though there are several common patterns.

5

KISSKISS

More than anything else though, keep it simple. Subversion is very powerful and has a lot of optional features. Tonight, I will touch on what I consider to be the most fundamental of those features. Try not to be tempted to dive too much into subversions advanced features until you actually need them. It's easy to get overwhelmed. By and large, if you don't know you need to know about something, it's safe to ignore.

6

What OS should I use for a What OS should I use for a Subversion server?Subversion server?

The big question. Subversion is ”native” to Linux, but Tigris makes binaries for Windows, Linux, and OSX. So, which is ”best”?

7

Well, it depends.Well, it depends.

My standard answer for which server is ”best” is ”Whichever one you know how to use better.” The big three platforms are all technologically comparable, each with their own strengths and weaknesses. The biggest differentiating factor among them are the people, and the business goals that are creating the needs that you are attempting to fill.

Visual SVN Server for Windows is free and easy to deploy and manage, and is essentially a well-packaged ”standard” subversion server with an Apache front-end. So if you have a Windows infrastructure, there's no need to introduce Linux just to get a Subversion server.

I have no experience running Subversion on OSX, but from what I understand, it's comparable to running it on Linux.

8

Deployment ConsiderationsDeployment Considerations

Transport methods? Ssh, svn, https. HTTPS is generally the most flexible, though it can be a bit harder to get going initially (not so with VisualSVN server)

Backend? DBD or FSFS? Slightly different performance profiles in some corner cases, but FSFS is gernally more robust, and the default in recent versions of subversion. Use FSFS unless you know you need DBD.

Allow anonymous reading?Deployment considerations around security will

generally be driven by choices made about repo layout.

9

One Repo or Many?One Repo or Many?

Don't make this harder than it needs to be. A lot of people get hung up on this. The biggest question is whether or not to have all your projects in one repository, or to have many repos.

Keeping things in one repo makes sharing things among projects easier, but can make management a bit trickier, even if it is superficially more expedient.

It can be useful to have a repo per-project if at some point one needs to have different hooks for the projects. Subversion also uses repo-level commit revision numbers, so it can be confusing if revision numbers in a project are non-sequential.

I tend to create one repo for each project. I like the atomic level of control it provides. Though, again, there is no one ”right” way to do it.

10

Repo Structure?Repo Structure?

Again, don't get hung up on this. Just use what makes sense. You'll learn what works for you and what doesn't as you go. If in doubt, just start with the typical Trunk/Branches/Tags base structure and go from there. You can always re-arrange later if you need to.

11

Repository Server Repository Server MaintenanceMaintenance

In most cases, once the server is deployed, there is little to be done in terms of administration. Typically, one needs only worry about creating new repos and backing up existing repos. In more complex environments there is more to it, like managing commit hooks, but that is well beyond the scope of this presentation.

For backups, I use a two-pronged approach. I have a second server which mirrors the main server's repos every few hours. This allows the secondary server to be used as read-only ”failover” in emergencies with virtually no config neccesary. However, this does not backup each individual repo's security settings and other configurations. To get that information I use dirvish to backup the repos, omitting the actual repo contents.

12

Typical WorkflowTypical Workflow

●Checkout●Add files / change files●Checkin / merge●Repeat

13

Keeping a working copy Keeping a working copy healthyhealthy

Bottom line, ”don't touch it, you'll break it.” If you must touch it, use the svn tools to do it, not the OS level functions. Moving, renaming, or deleting files or directories with the OS tools will break subversion's view of the contents of the working copy. You don't want to have to deal with fixing this. It can be a pain.

14

LockingLocking

Lock binary files when you work on them. Merging parallel changes in binary files is hard.

As implemented in Subversion, locks should be thought of as a communication tool. If you find a locked file that you need to work on, you should take that as a prompt to talk to the person that locked it and find out why it is locked. If that person is unavailable, you can usually break locks very easily. Most consider that to be an anti-social behavior and should be avoided if you want to stay on good terms with your work mates.

15

Branching and MergingBranching and Merging

Again, branches and tags are just normal directories to subversion that happen to have some extra historical metadata associated with them.

Don't get overzealous in using branches and tags. Except in very large projects with large numbers of people working, in practice, branching is often an unneccesary hassle.

16

Typical Branch / Tag Typical Branch / Tag workflowworkflow

Release branches/tags – All work goes on in trunk, once a major release (1.0) is ready, a branch and a tag is created for that release (/branches/1.0 , /tags/1.0). The tag is static at that point. Work on 1.x continues on the major version branch, and a point-release may be made and copied into tags (/tags/1.1). Meanwhile, work continues towards 2.0 in trunk. Trunk may be broken at any time, but trunk is always where latest work happens, so the need for large, complex merges is largely avoided.

”Trunk is Stable” (AKA ”Feature Branches”)- This is sort of the logical reverse of the last example. All the development is done in private branches, which are periodically merged into the trunk by someone who vets each merge to make sure that they don't break anything. This seems to be the most common workflow in OSS projects, probably because it accomodates their fluid nature more easily and makes ”user” checkouts of stable code simpler.

17

Reverting to previous Reverting to previous versionsversions

”What was I thinking?!” A core feature of a version control system is the ability to revert a file or files to a previous state easily.

This is easy to do with uncommitted changes. Once changes are committed it becomes more complex. If you are only one version away, you can ”diff with previous version” and easily see and edit out the bad choices. If you are multiple versions out, you will need to ”update to a previous version” and then manually resolve conflicts, or, ”export” the file you want from a previous version and manually place it contents into your working copy. The ”export and insert” method is probably the most straightforward.

18

Further ReadingFurther Reading

http://svnbook.red-bean.com/

http://svnbook.red-bean.com/

The Subversion Book. Pretty much the definitive resource. The same content you get in O'reilly's book.

http://www.tortoisesvn.net/docs/release/TortoiseSVN_en/index.html

TortoiseSVN Manual

http://www.tortoisesvn.net/docs/release/TortoiseMerge_en/index.html

Tortoise Merge Manual