HOWTO Start working with Subversion
From Consultancy.EdVoncken.NET
Subversion, one of the popular Version Control Systems, is quite easy to set up. In this example, I'll create and initialize a locally hosted repository. Make sure you read Version Control with Subversion - it is free, and I highly recommend it!
Contents |
Note: Mac OS X 10.5 Leopard ships with Subversion 1.4.4 pre-installed, on Linux you may have to install Subversion (e.g. "yum install subversion").
I highly recommend installing Subversion 1.6.x - I use the MacPorts Subversion port for Leopard:
$ sudo port install subversion +mod_dav_svn +tools +bash_completion
[edit] Repositories
I decided to store my Subversion Repositories under my home directory. Since I work for multiple customers, I want to give them independent repositories to keep the work isolated. For Customer1, everything can go into one repository (no projects needed):
$ mkdir -p /Users/ed/svnrepos/ $ svnadmin create /Users/ed/snvrepos/Customer1
Customer2 requires the use of separate repositories for each of their projects, so I need to add another directory level:
$ mkdir -p /Users/ed/svnrepos/Customer2 $ svnadmin create /Users/ed/snvrepos/Customer2/ProjectA $ svnadmin create /Users/ed/snvrepos/Customer2/ProjectB $ svnadmin create /Users/ed/snvrepos/Customer2/ProjectC
[edit] Workspaces
[edit] Create Workspaces
You should never work directly in the Repository - all work is done in "Workspaces" (local copies of the Repository). I keep these workspaces under my Documents/Work directory on Mac OS X:
$ cd /Users/ed/Documents/Work $ svn checkout file:////Users/ed/snvrepos/Customer1 Checked out revision 0. $ mkdir -p /Users/ed/Documents/Work/Customer2 $ cd /Users/ed/Documents/Work/Customer2 $ svn checkout /Users/ed/Documents/Work/Customer2/ProjectA Checked out revision 0. $ svn checkout /Users/ed/Documents/Work/Customer2/ProjectB Checked out revision 0. $ svn checkout /Users/ed/Documents/Work/Customer2/ProjectC Checked out revision 0.
[edit] Set up trunk/tags/branches
According to Best Practices in svn-book 1.5 (pdf), I use the standard "TTB" directories in each of my repositories:
$ cd /Users/ed/Documents/Work/Customer1 $ svn mkdir trunk tags branches A trunk A tags A branches $ svn commit . -m "Created initial repository layout" Adding branches Adding tags Adding trunk
The contents of your working copy and repository are now in sync:
$ ls -l total 0 drwxr-xr-x 3 ed staff 102 Apr 21 12:36 branches drwxr-xr-x 3 ed staff 102 Apr 21 12:36 tags drwxr-xr-x 3 ed staff 102 Apr 21 12:36 trunk
Do the same for the other repositories:
$ cd /Users/ed/Documents/Work/Customer2/ProjectA $ svn mkdir trunk tags branches $ svn commit . -m "Created initial repository layout" $ cd /Users/ed/Documents/Work/Customer2/ProjectB $ svn mkdir trunk tags branches $ svn commit . -m "Created initial repository layout" $ cd /Users/ed/Documents/Work/Customer2/ProjectC $ svn mkdir trunk tags branches $ svn commit . -m "Created initial repository layout"
Done! Now, you should switch to the proper trunk, tag or branch before adding files or directories to your workspace.
[edit] Switching between trunks, tags and branches
To reconfigure your workspace for a particular trunk, tag or branch, use the svn switch command from inside your workspace:
$ cd /Users/ed/Documents/Work/Customer2/ProjectA/ $ svn switch /Users/ed/snvrepos/Customer2/ProjectA/trunk
[edit] Branching and Merging
[edit] Branching
Let's say you you suddenly need to make an important change, without impacting the main line of development. This is where "branching" comes into play:
$ svn copy file:///Users/ed/snvrepos/Customer2/ProjectA/trunk file:///Users/ed/snvrepos/Customer2/ProjectA/branches/CR20090420
You now check out the newly created branch, for example in a fresh workspace (you can have as many as you like...)
$ cd /Users/ed/Documents/Work/ $ svn checkout file:///Users/ed/svnrepos/Customer2/ProjectA/branches/CR20090420 CR20090420
This will create a workspace in /Users/ed/Documents/Work/CR20090420. Now, you can edit/add/remove files or directories, implementing the Change Request.
To review your changes, use the "svn status" command:
$ svn status M bar.c ? foo.c ? foo.h
We created two new files, so let's add those:
$ svn add foo.c foo.h A foo.c A foo.h $ svn status M bar.c A foo.c A foo.h
Good. Let's commit the changes in this branch to the repository:
$ svn commit . -m "Implemented CR20090420: Added new feature foo" Sending CR20090420/bar.c Adding CR20090420/foo.c Adding CR20090420/foo.h Transmitting file data ... Committed revision 7.
[edit] Merging
Once your change has been tested and approved, it should probably be incorporated in the main development line, (usually /trunk). To do this, we will merge the changes in the CR20090420 branch (revision 7) back to the trunk.
We need to change to a workspace that contains the /trunk (or switch an existing workspace to /trunk):
$ cd /Users/ed/Documents/Work/Customer2/ProjectA/
Before doing the actual merge, do a dry run to see if the results match your expectations:
$ svn merge --dry-run file:///Users/ed/svnrepos/Customer2/ProjectA/branches/CR20090420
If all seems well, run the actual merge:
$ svn merge file:///Users/ed/svnrepos/Customer2/ProjectA/branches/CR20090420
If you encounter merge conflicts, you may need to resolve them manually. Afterwards, you will need to tell Subversion that the conflict has been resolved, for example:
$ svn resolve --accept=working foo.c
Otherwise, "svn commit" will complain and refuse to proceed.