SVN Basic Usage Guide

This is a very basic quick start guide to the most common SVN commands.

Creating a Repository

Use the svnadmin command to create and manage repositories:

svnadmin create /path/to/repository

Importing files into repository

To import existing dirs and files into the repository:

svn import /tmp/project file:///path/to/repos -m "initial import"

Checking out files

To check out a new working copy of a repository to begin working on it:

svn checkout file:///path/to/repository project

SVN Status command

To see the status of your working copy, run svn status which will produce output similar to:

?      dir/file
M      dir/dir2/file2
D      dir/dir3/file3

TODO - detail what the letters mean.

Committing files

As simple as:

svn commit file -m 'my commit message'

If the filename is missed out, svn commit will commit all changes to the working copy you're in.

If the log message isn't supplied with the -m param, svn will start whatever visual editor it is configured to use and wait for you to write a log entry. If you quit the editor without saving, you'll be asked if you want to abort the commit.

If you already have a commit message you'd like to use in a file (perhaps because the last commit failed for whatever reason, so the message you'd entered was saved in svn-commit.tmp), use the -F flag instead to specify a file to read the commit message from.

Tip: I strongly recommend never using the -m param, and always entering your commit message in your editor instead - this means that you'll be presented with the list of files about to committed whilst you write your log entry, and will notice if the commit operation is going to commit other changed files which you didn't want to commit yet.

Obviously you'll see the list of files about to be committed if you do svn status first, but if you get lazy, or very busy, one day you will forget about some other change which isn't yet complete, forget to do svn status, and watch as files you didn't want to commit yet get sent on their merry way into the repo.

Undoing commits

If you've made a dodgy commit which you'd like to undo, you can use svn merge.

Create a new working copy (to save the changes you committed by mistake so they can be actually committed in the near future - just check out a working copy in the normal way.

Now, from that working copy, do:

svn merge -r badrev:prevrev .

Where badrev is the revision number where you just made the balls-up and prevrev is the revision number before the cockup.

Now, use svn status / svn diff to check that everything is as expected, then commit.

Update - actually, reading that back now, you should be able to just check out a copy of the repo as it was in the previous revision, with svn checkout -r PREV, then commit that?

Branching - a quick guide

When doing anything more than quick changes, you probably want to create a branch to do your development in, then merge your changes back into the trunk when your project is complete.

This will assume that your repository contains a directory layout like:

trunk/       -- the "current" version
branches/    -- branches for projects underway

(you might also have a tags/ directory for release snapshots etc).

So, you want to start a new branch to do some work.

Creating new branch

First, create your branch, as a copy of the trunk. Branches are really nothing more than a copy of the trunk where you can develop without changing the trunk until you're ready to deploy your changes.

Note : in all the following examples, ”<repo-path>” is the path to the repository, which might be a file:/ path, a http: URL to the repository served by svnserve, or an svn+ssh: path... whatever you would use in an svn checkout command, use here. <code> $ svn copy <repo-path>/trunk <repo-path>/branches/mybranch </code> You can now check out a copy of the new branch in the normal way. Alternatively, as long as your working copy is up to date (do svn update first) and you have no uncommitted stuff in it, you could just copy trunk in your working copy to branches/mybranch in your working copy, check it's OK, then commit it. During development, you'll work in branches/mybranch and commit as normal. When you're done, you'll need to merge all changes from the trunk into your branch (if it's a long project, you might want to do this now and then during the project, so that your branch is never too far from the state of the trunk - this will avoid nasty surprises further down the line). ==== Merging changes from trunk into branch ==== To merge changes from trunk to branch, so that your branch contains all changes that you or others have made to the trunk since the branch was created (or since changes from the trunk were last merged in): <code> # change into your working copy of the branch $ svn merge -r 123:HEAD <repo-path>/trunk $ svn status # to check it's as you'd expect $ svn commit -m 'merging changes from trunk into mybranch' </code> If you were to do the merge directly on the repository, you could do the merge like: <code> $ svn merge -r 123:HEAD <repo-path>/trunk <repo-path>/branches/mybranch </code> “123” above represents the revision that the branch was first created in, OR the last time you merged changes from the trunk to the branch. svn log will tell you - give it the –stop-on-copy option, and you'll see only the history of the branch, from when it was created onwards. ==== Merging from branch to trunk (changes are complete) ==== Now, you'll merge your changes from your branch into the trunk, with something like: <code> $ svn update branches/mybranch At revision 140 $ svn merge -r 123:HEAD <repo-path>/branches/mybranch <repo-path>/trunk </code> When performing merges, it's well worth using the –dry-run option first, so that you can see what it would have done before actually doing it. Also, you could do the merge on your local working copy, then commit when you're happy with it - that would be much safer than doing the merge directly on the repository.

svn/basicguide.txt · Last modified: 2010/02/26 10:45 (external edit)
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki