Subversion Cheat Sheet

Subversion Cheat Sheet

Graphic showing SVN hierarchy

This Subversion cheat sheet was created during the initial setup of Subversion on Apache 2.0 on Windows and Mac OS X. A detailed tutorial covering most of the features of Subversion can be found in the online Subversion book. However, to make Subversion more useful for me, I created this Readers’ Digest version.

Checking Out a Project – svn checkout

To start using the version control features check out a project into your local working directory. This is done with the following command:

UNIX

svn checkout file:///repository_name/project/trunk project

Windows

svn checkout file:///d:/repository_name/project/trunk project

Network

svn checkout http://host_name/svn_dir/repository_name/project/trunk project

Reviewing Changes – svn status

To see what files you have changed or added to your checked out work, use the update command:

UNIX

svn status

svn status -u

This command will give you a listing of new files, files that have been changed, and files that have been deleted. New files or deleted files must be added or removed using the add and delete commands (see more below.)

Committing Changes – svn commit

Once you have added, deleted, or changed files or directories, you can then commit those changes to the repository. This command is pretty straightforward:

Network

svn commit -m "Saving recent changes" http://localhost/svn_dir/repository/project_dir

Updating Your Local Files – svn update

If you have a set of files checked out and would like to update them to the most recent version of files in the repository, use the update command.

Network

svn update

If there are newer files in the repository, they will overwrite any files you have locally. Before using this command, you may want to use the svn diff command to find out what the differences are between your local files and the repository.

Tagging Projects or Creating Project Specific Versions

Subversion does not track the version numbers for individual projects automatically. Instead, it tracks each update to the repository and tracks the versions of these updates. To create interim project releases, you must create “Tags” which identify a specify version of a project. This is done by making a virtual copy of a project in the tags directory. For example:

svn copy http://host_name/repos/project/trunk http://host_name/repos/project/tags/0.1.0 -m "Tagging the 0.1.0 release of the project"

This creates a sort of bookmark or snapshot which records the current state of the project. Then, you can checkout the project in this state at any time by simply referring to that release number.

To get a list of the releases for a project.

svn list http://192.168.0.4/svn/repos/prj1/tags
0.1.0/

Release 0.7.2 of SCPlugin (for svn 1.4.x or 1.5.x)

2008/07/05 – Announcing Release 0.7.2 of SCPlugin!

SCPlugin Finder Integration contextual menu
I’ve just put up the final release of 0.7.2, in the usual place. This release makes major improvements in user name / password handling, appearance, and personalization, and now supports your choice of Subversion 1.4.6 or 1.5.0. I encourage all users to upgrade. See the announcement for full details.

More at scplugin.tigris.org

iBanjo » Blog Archive » Subversion’s Future?

iBanjo » Blog Archive » Subversion’s Future?

I have to say, after using Mercurial for a bit, I think distributed version control is pretty neat stuff. As Subversion tests a final release candidate for 1.5 (which features limited merge-tracking abilities), there’s a bit of angst going on in the Subversion developer community about what exactly the future of Subversion is. Mercurial and Git are everywhere, getting more popular all the time (certainly among the 20% trailblazers). What role does Subversion — a “best of breed” centralized version control system — have in a world where everyone is slowly moving to decentralized systems? Subversion has clearly accomplished the mission we established back in 2000 (”to replace CVS”). But you can’t hold still. If Subversion doesn’t have a clear mission going into the future, it will be replaced by something shinier. It might be Mercurial or Git, or maybe something else. Ideally, Subversion would replace itself. If we were to design Subversion 2.0, how would we do it?

 

Last week one of our developers wrote an elegant email that summarizes a potential new mission statement very well. You should really read the whole thing here. Here’s a nice excerpt: