Architecture and Design of Subversion - SVN (Part 1)

Hi everybody, today I want to discuss about Subversion, or SVN – a version control system, which manage our source code based on revision, sometimes called Version Control or Source Control. I will use definition about Version Control and SVN in this post.

Design of Subversion, or SVN?

Version Control is a definition in Software Configuration Management, is management of data system by assigning to every changes inside system a index which can be number (with SVN) or a string (with Git), this index is called revision number, or revision level, or simply revision.

For example: my project has one file named TestNetwork.java, I started with very begining main() function which has some System.out.prinln(), then I put this file onto version control system, I have resivion 1.

Then I start to add more code, like int x = 6; x += 5; etc. Now when I put this file again onto version control system, I will have revision 2.

One big benefit of version control systems is, we can work with any revision. It means we can back to revision 1, 2, or 100 without undo or redo inside our editor. Also, we can find out what was added/remove/changed by our team.

So, we can understand that, using Version Control, we can control and track any changes of data inside project, which can be many format like: code, database, schema, documentation, asset, configuration, binary or even multimedia.

Subversion

Subversion, 1 a free and open source Version Control System, powered by CollabNet and Apache, is used inside many systems and projects all over the world, for example: Apache Software Foundation, KDE, GNOME, Free Pascal, FreeBSD, GCC, Python, Django, Ruby hay Mono.

Subversion has following architecture:

![ch01dia1](https://co

Subversion has one Repository, which act like server stores data, provide interface for client. Client can be a GUI or a simple CLI, based on a subversion library for transferring data.

Subversion usually uses structure with 3 folders:

• trunk: contains latest source code, which is on development
• tags: contains snapshot of project. For example: Project A releases version 1.0, all sources inside trunk will be tagged into 1.0 tag, and later, when we need to build/deploy or review version 1.0 again, we will get the tag 1.0
• branches: contains different branches of project. Developers can work on multiple, simultaneous features without affecting others. Branches can be merged later after feature has been implemented

A sample Subversion branches and tags:

[

The photo above represents development status of a repository, with several actions within Version Control System.

1. Trunk folder of repository
2. From trunk folder, create new branch for development
3. Work with new branch
4. After new branch had completed its own feature, merge it with main branch. Project is stable now and will be tagged as T1
5. Continue to develop
6. Continue to develop
7. New branch is created
8. New branch is created
9. New branch is completed, merge it onto main branch
10. This branch is discontinued, development is no longer active

Definition within SVN

• reposiroty: server which contain source and subversion
• HEAD: top position of SVN
• master: default, main branch which should be created when create SVN
• change: change between a revision, which previous revision
• working copy: copy of all subversion sources at local computer
• conflict: when many people work simultaneously with a same working copy, for example: A and B checkout revision 40 of file config.js, then A updates function update(), commits it to SVN to make revision 41 while B is updating the same function, when B checkout SVN to local working copy, SVN is unable to know what version is latest: A’s version or B’s version, and we call that situtation is conflict
• resolve: now B should review code inside function (which will be marked as conflict inside file config.js), to keep A’s code or update it to work with B’s source, then B will mark the conflict as resolved

Some important actions

commit: when developer changes code, architecture, structure, documentation,… and puts it on server, this is called commit, the commit should contains a message which describe the change of that commit, every commit will increase revision of SVN by 1

checkout: user who has credential to access to SVN and get content of the SVN at a specific revision, usually latest one, this revision is called HEAD – top position of SVN structure.

revert: after made some changes, developers think it was a mistake and want to clear all the changes they had made, they will revert – restore state of 1 or many documents to a specific revision, usually they will revert to current revision which they are working on.

merge: merging code from different branch to one, the second branch will be redirected to first branch.

update: when we update working copy will take current working copy to selected revision

Tool

Many people like to use CLI when working with SVN (including me), but others like to use GUI. With GUI, we have some good choices like Cornerstone and Versions for OS X, and of course, TortoiseSVN for Windows. In next post, we will dive deeply onto some commands and architecture at server-side of SVN.