HOWTO Start working with Subversion

HOWTO Start working with Subversion

From Consultancy.EdVoncken.NET

Jump to: navigation, search

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.