Apache Subversion which is often abbreviated as SVN, is a software versioning and revision control system distributed under an open source license. Subversion was created by CollabNet Inc. in 2000, but now it is developed as a project of the Apache Software Foundation, and as such is part of a rich community of developers and users.

Subversion is a free/open source version control system (VCS). That is, Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data, or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of “time machine.”

Subversion can operate across networks, which allows it to be used by people on different computers. At some level, the ability for various people to modify and manage the same set of data from their respective locations fosters collaboration. Progress can occur more quickly without a single conduit through which all modifications must occur. And because the work is versioned, you need not fear that quality is the trade-off for losing that conduit—if some incorrect change is made to the data, just undo that change.

Some version control systems are also software configuration management (SCM) systems. These systems are specifically tailored to manage trees of source code and have many features that are specific to software development—such as natively understanding programming languages, or supplying tools for building software. Subversion, however, is not one of these systems. It is a general system that can be used to manage any collection of files. For you, those files might be source code—for others, anything from grocery shopping lists to digital video mixdowns and beyond.

Architecture and Design of Subversion – SVN

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.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:

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 figure  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.

SVN – Life Cycle

Create Repository:

The repository is a central place where developers store all their work. Repository not only stores files, but also the history about changes. Which means it maintains a history of the changes made in the files.The ‘create’ operation is used to create a new repository. Most of the times this operation is done only once. When you create a new repository, your VCS will expect you to say something to identify it, such as where you want it to be created, or what name should be given to the repository.

Checkout

‘Checkout’ operation is used to create a working copy from the repository. Working copy is a private workplace where developers do their changes, and later on, submit these changes to the repository.

Update

As the name suggests, ‘update’ operation is used to update working copy. This operation synchronizes the working copy with the repository. As repository is shared by all the teams other developers can commit their changes and your working copy becomes older.Let us suppose Tom and Jerry are the two developers working on a project. Both check out the latest version from the repository and start working. At this point, their working copies are completely synchronized with the repository. Jerry completes his work very efficiently and commits his changes to the repository.Now Tom’s working copy is out of date. Update operation will pull Jerry’s latest changes from the repository and will update Tom’s working copy.

Perform Changes

After the checkout, one can do various operations to perform changes. Edit is the most common operation. One can edit the existing file to add/remove contents from the file.One can add files/directories. But immediately these files/directories do not become a part of the repository, instead they are added to the pending change-list and become a part of the repository after the commit operation.Similarly one can delete files/directories. Delete operation immediately deletes file from the working copy, but actual deletion of the file is added to the pending change-list and changes are made to the repository after the commit operation.’Rename’ operation changes the name of the file/directory. ‘Move’ operation is used to move files/directories from one place to another in a repository tree.

Review Changes

When you check out the working copy or update the working copy, then your working copy is completely synchronized with the repository. But as you do changes to your working copy, it becomes newer than the repository. And it is a good practice to review your changes before the ‘commit’ operation.’Status’ operation lists the modifications that have been made to the working copy. As we have mentioned before, whenever you do changes in the working copy all these changes become a part of the pending change-list. And the ‘status’ operation is used to see the pending change-list.’Status’ operation only provides a list of changes but not the details about them. One can use diff operation to view the details of the modifications that have been made to the working copy.

Fix Mistakes

Let us suppose one has made changes to his working copy, but now, he wants to throw away these changes. In this situation, ‘revert’ operation will help.Revert operation reverts the modifications that have been made to the working copy. It is possible to revert one or more files/directories. Also it is possible to revert the whole working copy. In this case, the ‘revert’ operation will destroy the pending change-list and will bring the working copy back to its original state.

Resolve Conflicts:

Conflicts can occur at the time of merging. ‘Merge’ operation automatically handles everything that can be done safely. Everything else is considered as conflict. For example, “hello.c” file was modified in branch and deleted in another branch. Such a situation requires a person to make the decision. The ‘resolve’ operation is used to help the user figure out things and to inform VCS about the ways of handling the conflicts.

Commit Changes

‘Commit’ operation is used to apply changes from the working copy to the repository. This operation modifies the repository and other developers can see these changes by updating their working copy.Before commit, one has to add files/directories to the pending change-list. This is the place where changes wait to be committed. With commit, we usually provide a log message to explain why someone made changes. This log message becomes a part of the history of the repository. Commit is an atomic operation, which means either the entire commit succeeds or it is rolled back. Users never see half-finished commit.

Using SVN in Windows

Installing Subversion

We need to get started with setting up our client. We will use TortoiseSVN for this. Just choose the 32-bit of 64-bit client, and install it onto your machine. You don’t need to reboot, despite the installer telling you to.

Creating our First Project

When you are ready, we can create a project folder. In this instance we will use c:\myproject. Because TortoiseSVN is just a shell extension, we can initialise SVN in myproject by right-clicking inside the folder and choosing SVN Checkout:

Now we need to enter the URL of the repository that is on our Codebase account, which in this case will be https://adamw.codebasehq.com/tester/svn_repo.svn. This can be found inside the main repository page, on the right hand side:

Everything else can be left as it is; it all gets automatically populated for a first checkout from the folder you are in, so just hit OK. Now you will be prompted for authentication, just use your codebase username and password, and again, hit OK.

A folder .svn will be created inside myproject.

Running our First Commit

Now we need to commit something, so let’s create a new folder inside myproject, and call it test. Once this is done, just right click inside the root of myproject, and click SVN Commit. A window will pop up showing the detected changes, in this case, a new folder:

We can type our commit message at top, then hit OK when we are ready. A similar message will pop up to when we first checked out. So we have created a nice easy client setup for SVN, and run our first commits. We can see the results of our first commit in codebase:

Setting up Subversion on Windows

c:svn

svnadmin create "c:svnrepository"

anon-access = none
auth-access = write
password-db = passwd

harry = harryssecret
sally = sallyssecret

sc create svnserver binpath= "c:svnbinsvnserve.exe --service -r c:svnrepository"
displayname= "Subversion" depend= Tcpip start= auto

net start svnserver

set SVN_EDITOR=c:windowssystem32notepad.exe
svn mkdir svn://localhost/myproject

svn mkdir svn://localhost/myproject
Authentication realm: <svn://localhost:3690>
Password for 'Administrator': [enter]
Authentication realm: <svn://localhost:3690>
Username: sally
Password for 'sally': ************
Committed revision 1.

–SVNManager is a PHP web based tool to administer a Apache Subversion repository server.

SVNManager is released under the BSD license

Welcome

Login

Create New Repository

Repository Administration

User Administration

Apache Subversion Features

• Most CVS features.CVS is a relatively basic version control system. For the most part, Subversion has matched or exceeded CVS’s feature set where those features continue to apply in Subversion’s particular design.
• Directories are versioned.Subversion versions directories as first-class objects, just like files.
• Copying, deleting, and renaming are versioned.Copying and deleting are versioned operations. Renaming is also a versioned operation, albeit with some quirks.
• Free-form versioned metadata (“properties”).Subversion allows arbitrary metadata (“properties”) to be attached to any file or directory. These properties are key/value pairs, and are versioned just like the objects they are attached to. Subversion also provides a way to attach arbitrary key/value properties to a revision (that is, to a committed changeset). These properties are not versioned, since they attach metadata to the version-space itself, but they can be changed at any time.
• Atomic commits.No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file, and commit’s log message is attached to its revision, not stored redundantly in all the files affected by that commit.
• Branching and tagging are cheap (constant time) operations.There is no reason for these operations to be expensive, so they aren’t.Branches and tags are both implemented in terms of an underlying “copy” operation. A copy takes up a small, constant amount of space. Any copy is a tag; and if you start committing on a copy, then it’s a branch as well. (This does away with CVS’s “branch-point tagging”, by removing the distinction that made branch-point tags necessary in the first place.)
• Merge tracking.Subversion 1.5 introduces merge tracking: automated assistance with managing the flow of changes between lines of development, and with the merging of branches back into their sources. The 1.5 release of merge tracking has basic support for common scenarios; we will be extending the feature in upcoming releases.
• File locking.Subversion supports (but does not require) locking files so that users can be warned when multiple people try to edit the same file. A file can be marked as requiring a lock before being edited, in which case Subversion will present the file in read-only mode until a lock is acquired.
• Symbolic links can be versioned.Unix users can place symbolic links under version control. The links are recreated in Unix working copies, but not in win32 working copies.
• Executable flag is preserved.Subversion notices when a file is executable, and if that file is placed into version control, its executability will be preserved when it it checked out to other locations. (The mechanism Subversion uses to remember this is simply versioned properties, so executability can be manually edited when necessary, even from a client that does not acknowledge the file’s executability, e.g., when having the wrong extension under Microsoft Windows).
• Apache network server option, with WebDAV/DeltaV protocol.Subversion can use the HTTP-based WebDAV/DeltaV protocol for network communications, and the Apache web server to provide repository-side network service. This gives Subversion an advantage over CVS in interoperability, and allows certain features (such as authentication, wire compression) to be provided in a way that is already familiar to administrators
• Standalone server option (svnserve).Subversion offers a standalone server option using a custom protocol, since not everyone wants to run an Apache HTTPD server. The standalone server can run as an inetd service or in daemon mode, and offers the same level of authentication and authorization functionality as the HTTPD-based server. The standalone server can also be tunnelled over ssh.
• Parseable output.All output of the Subversion command-line client is carefully designed to be both human readable and automatically parseable; scriptability is a high priority.
• Localized messages.Subversion uses gettext() to display translated error, informational, and help messages, based on current locale settings.
• Interactive conflict resolution.The Subversion command-line client (svn) offers various ways to resolve conflicting changes, include interactive resolution prompting. This mechanism is also made available via APIs, so that other clients (such as graphical clients) can offer interactive conflict resolution appropriate to their interfaces.
• Repository read-only mirroring.Subversion supplies a utility, svnsync for synchronizing (via either push or pull) a read-only slave repository with a master repository.
• Write-through proxy over WebDAV.Subversion 1.5 introduces a write-through proxy feature that allows slave repositories to handle all read operations themselves while passing write operations through to the master. This feature is only available with the Apache HTTPD (WebDAV) server option.
• Natively client/server, layered library design with clean APIs.Subversion is designed to be client/server from the beginning; thus avoiding some of the maintenance problems which have plagued CVS. The code is structured as a set of modules with well-defined interfaces, designed to be called by other applications.
• Binary files handled efficiently.Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions.
• Costs are proportional to change size, not data size.In general, the time required for a Subversion operation is proportional to the size of the changes resulting from that operation, not to the absolute size of the project in which the changes are taking place.
• Bindings to programming languages.The Subversion APIs come with bindings for many programming languages, such as Python, Perl, Java, and Ruby. (Subversion itself is written in C.)
• Changelists.Subversion 1.5 introduces changelists, which allows a user to put modified files into named groups on the client side, and then commit by specifying a particular group. For those who work on logically separate changesets simultaneously in the same directory tree, changelists can help keep things organized.

Major Features of  SVNManager

With this tool you can remotely

• Create, remove, load and dump repositories
• Manage user accounts for access to the repositories
• Manage groups for acces to the repositories
• Invite users by email to create an account on the server