This document provides an overview of using Subversion (SVN) for version control of software projects. It demonstrates how to [1] create an SVN repository and import an initial project, [2] check out a working copy to make changes, [3] commit changes back to the repository, [4] allow multiple developers to collaborate by updating and committing changes, [5] branch and tag different versions, and discusses the benefits of using SVN like unlimited undo capabilities and enforcing structured development.

1. A day with Subversion (SVN)
Sebastian Heimann
Institut f¨r Geophysik, Arbeitsgruppe Seismologie
u
February 15, 2007

2. Outline
1. Concepts (by example)
2. Vocabulary
3. Benefits
4. Further reading

3. The initial work
Let’s assume we have just made a quick and dirty hack, which we
now want to put under version contol for further development:
> ls /my/hack

4. Create an empty repository
> svnadmin create --fs-type fsfs /my/repos
Repository

5. The initial import
> svn import /my/hack file:///my/repos/hack/trunk
-m ’Initial import’
Repository
1

6. Checkout a working copy of hack
> svn checkout file:///my/repos/hack/trunk /work/hack
Repository
Working copy
1

7. Add a new feature to hack
> cd /work/hack ; vi hack
Repository
Working copy
1

8. Commit your changes to the repository
> svn commit
Repository
Working copy
2
1

9. More than one person can now work on hack
Repository
Fu’s working copy 2 Fara’s working copy
1

10. Both implement their improvements
Repository
Fu’s working copy 2 Fara’s working copy
1

11. Fu commits his changes to the repository
Repository
> svn commit
3
Fara’s working copy
Fu’s working copy
2
1

12. Fara commits her changes to the repository
Repository
4
> svn commit
Fu’s working copy
3
Fara’s working copy
2
1

13. To get each others changes
Repository
4
> svn update > svn update
3
Fu’s working copy Fara’s working copy
2
1

14. Fu and Fara can go back to any previous revision
Repository
4
> svn update -r 1 > svn update -r 3
3
Fu’s working copy Fara’s working copy
2
1

15. Internally the repository will only store differences...
Repository
4
3
2
1

16. ...but it pretends to make a new copy on every commit.
Repository
4
3
2
1

17. Sometimes it may be useful to branch the project...
> svn cp -r 2 file:///my/repos/hack/trunk
file:///my/repos/hack/branches/mad

18. ...this creates a copy directly in the repository.
4
3
.../trunk .../branches/mad
2 5
1

19. Check out a working copy of the branch
> svn checkout file:///my/repos/hack/branches/mad
/work/mad-hack

20. You can now safely experiment with mad-hack, while
maintaining a stable version of hack in the trunk.
4
> cd /work/mad-hack
> # edit it 3 6
2 5
1
> svn commit

21. Tagging: You can also use the branching mechanism to
mark a specific revisions as somehow special.
> svn cp -r 2 file:///my/repos/hack/trunk
file:///my/repos/hack/tags/stable-v1

22. Tagged stable version 1 of hack
4
3
.../trunk .../tags/stable-v1
2 5
1

23. Vocabulary
repository
revision
working copy
to check out
to commit
to update

24. Vocabulary
to branch
to merge
to tag

25. Conventions
hack/trunk
hack/branches/mad
hack/tags/stable-v1

26. Benefits
Unlimited undo!
Collaborate with others!
Enforces structured development
Makes you document what you are doing
Automatic changelog!
Helps you organize your mess in $HOME

27. Further reading
Tutorial
http://artis.imag.fr/~Xavier.Decoret/resources/svn/
Documentation (A good intro is in Chapter 2)
http://svnbook.red-bean.com/nightly/en/
Online help
> svn help
> svn [command] help