Create and using a Git repo into a SVN environment

If you want to use Git as your versioning system, you shouldn't only migrate every repository from SVN to Git, but you should also use Git locally. The Git-svn command will help you do this. It so happens that your team doesn't want to change its versioning system, or a project is way too big to migrate on a new versioning system. So, Git has a solution for you; how about using Git features without anyone knowing or caring?

The following diagram explains how to use Git inside an SVN environment. When executing a Git command, the SVN environment will not notice it because the Git-svn command will convert all your commands.

Setting up your repository

You assume that you already have an SVN repository and you want to use Git locally. As a first step, clone the SVN repository using this command:

$ git svn clone -s http://mysvnrepo/svn/myproject myproject_gitsvn_local

The -s option stands for standard layout, which means that your subversion layout has three directories (trunk, branches, and tags). You can, of course, forget this option if your repository does not have a standard layout.
This creates a Git repository under the myproject_gitsvn_local directory that is mapped to the trunk folder of your subversion repository.
As Git doesn't track empty directories, the empty directories under the trunk won't appear inside your Git repository.
Sometimes you might have to clone a big repository. In this case, checking out the commit history will be lengthy because the repository is too big. There is a way to clone it without waiting for a long time. You can do this by cloning the repository with the earlier version of the repository:

$ git svn clone -s -r625:HEAD http://mysvnrepo/svn/myproject myproject_gitsvn_local

There is one last thing to set up. Every file ignored by SVN has to be ignored by Git too. To do this, you have to transfer them into the .gitignore file by using this:

$ git svn show-ignore > .gitignore

There is an alternative method that uses the update-index command:

$ git update-index --assume-unchanged filesToIgnore

Working with Git SVN

Once your repository is ready, you can work on it and start executing Git commands as we saw earlier. Of course, there are some commands to execute when you want to push or pull from the SVN repository. When you want to update your local Git repository, just type this:

$ git svn rebase

To commit back to SVN, use the following command:

$ git svn dcommit

Sooner or later, you will add the .svn folder to the staging area in Git. Hopefully, there is a way to delete it:

$ git status -s | grep .svn | awk "'print $3'} | xargs git rm -cached

How to freeing space from svn repository

With the passage of time, considerably increases the disk space used by svn repository. While the cost of storage has dropped incredibly in the past few years, disk usage is still a valid concern for administrators seeking to version large amounts of data so the maintenance activities about to free disk space becomes necessary. Some of them are:

• Removing dead transactions;
• Purging unused Berkeley DB logfiles;
• Packing FSFS filesystems;
• Purging the svn history.

Removing dead transactions

Though they are uncommon, there are circumstances in which a Subversion commit process might fail, leaving behind in the repository the remnants of the revision-to-be that wasn't an uncommitted transaction and all the file and directory changes associated with it.
You can use the svnadmin lstxns command to list the names of the currently outstanding transactions and remove them with "svnadmin rmtxns" command.

Example: 

$ svnadmin lstxns myrepos
27
4c3
w33
$ svnadmin rmtxns myrepos `svnadmin lstxns myrepos`

Purging unused Berkeley DB logfiles

Removing unused Berkeley DB logfiles allows you to free disk space. Use the svnadmin list-unused-dblogs command to list the unused logfiles and remove them.
Example:

$ svnadmin list-unused-dblogs /var/svn/repos
/var/svn/repos/log.0000000127
/var/svn/repos/log.0000000128
/var/svn/repos/log.0000000129
$ rm `svnadmin list-unused-dblogs /var/svn/repos`

Prune the history

Also you can prune your history. For example: say you have 180 revisions, you can keep the latest history, say 30 revisions. This may also reduce the size of your subversion repository.

$ svnadmin dump /path/to/current/repo -r150:180 > newsvn.dump
# you can delete the old repo and then
$ svnadmin create /path/to/new/repo
$ svnadmin load /path/to/new/repo < newsvn.dump

Packing FSFS filesystems

FSFS-backed Subversion repositories create, by default, a new on-disk file for each revision added to the repository. Having thousands of these files present on your Subversion server, even when housed in separate shared directories, can lead to inefficiencies. To solve this problem, you can use "svnadmin pack" command. By concatenating all the files of a completed shard into a single “pack” file and  then removing the original per-revision files, svnadmin pack reduces the file count within a given shard down to just a single file. In doing so, it aids filesystem caches and reduces (to one) the number of times a file storage overhead penalty is paid.

Example:

$ svnadmin pack /var/svn/repos
Packing shard 0...done.
Packing shard 1...done.
…
Packing shard 100...done. 

A relevant consideration is that the svnadmin pack command has no effect on BDB-backed Subversion repositories.

Getting started with subversion command-line

The following list contains the svn commands most used by a developer:

• Checkout
• Update
• Status
• Commit
• Add
• Revert 
• Move
• Delete

The following paragraphs will show examples of these svn commands using the command line interface (CLI).

svn checkout 

Check out a working copy from a repository. Use the following command for the check out of last revision:

 svn co <path_svn>

or

 svn checkout <path_svn>

Examples:

 svn co https://mysvnrep/svn/myproject/trunk

 svn checkout https://mysvnrep/svn/myproject/trunk

It's possible make the check out with the rename of folder name target:

 svn co <path_svn> <folder_name>

Example:

 svn co https://mysvnrep/svn/myproject/trunk myproject

Finally, you can check out of a precision revision

 svn co -r <revision_number> <path_svn>

Example:

 svn co -r 236 https://mysvnrep/svn/myproject/trunk

svn update

Update your working copy with a revision version.

 svn up [-r<revision>]

or

 svn update [-r<revision>]

Note: -r (alias --revision).
If you want update your working copy with the last revision use (without -r option):

 svn update

or

 svn up

svn status

Display the status of working copy files and directories. Diff between your workspace and code repository.

 svn stat <path>

or

 svn st <path>

or

 svn status <path>

<path> is optional parameter, the default value is current folder ( . ). The command output shows the file list with the status for each file. The following status are the most common:

 'A' Item is scheduled for addition.
 'D' Item is scheduled for deletion.
 'M' Item has been modified.
 '?' Item is not under version control.
 '!' Item is missing (e.g., you moved or deleted it without using svn). This also indicates that a directory is incomplete (a checkout or update was interrupted).
 '~' Item is versioned as one kind of object (file, directory, link), but has been replaced by a different kind of object.

svn commit

Send changes from your working copy to the code repository. After the commit from an user X, the changes are available from other users using the svn update command. For commit all files with status changed (M, A, D, etc...) use:

 svn commit -m "<a comment>"

or

  svn ci -m "<a comment>"

If you want commit only a subset of files:

  svn commit -m "<a comment>" file1 file2 ....

Example:
Status before commit

 svn stat
 M Employ.java
 A myPackage/Person.java

Commit only Person.java

 svn commit -m "added Person.java" myPackage/Person.java

Status after commit

 svn stat
 M Employ.java

svn add

Add a new file (or folder) under source control, use the add command:

  svn add <file>

After that use the commit command for send the changes to code repository.

  svn ci -m "a comment" <file>

svn revert

Undo all locat edits. Yuo can revert all files or folders with status A, M and D.

 svn revert <path>

Examples:
Revert a folder edited

 svn revert myfolder
 Reverted myfolder

Revert a file added

 svn add myfile.txt
 A myfile.txt
 svn revert myfile.txt
 Reverted myfile.txt
 svn status
 ? myfile.txt

If you want to revert a whole directory of files, use the "--depth=infinity" option:

 svn revert --depth=infinity .
 Reverted myfolder
 Reverted myfile.txt

svn move

Move a file or directory.

 svn move <src> <dst>

or

 svn mv <src> <dst>

The <src> and <dst> can be local path or url.
Examples:
Use move command in your working copy

 svn move myfile.txt myfile2.txt
  A myfile2.txt
  D myfile.txt

Use the commit command to update the svn repository

 svn ci -m "move example"
 Committed revision 1233

Use move command with url

 svn move -m "move example 2" https://mysvnrepo/svn/trunk/myfile.txt https://mysvnrepo/svn/trunk/myfile2.txt
 Committed revision 1234

svn delete

Delete an item from a working copy or the repository.

 svn delete <url or path file>

or

 svn del <url or path file>

or

 svn remove <url or path file>

or

 svn rm <url or path file>

Example: to delete a file or a directory from your working copy use the following command:

 svn delete MyFile.txt 

After that, you can see the local status

 svn stat
 D MyFile.txt

If you want delete the file in repository then you must execute the commit

 svn ci -m "Delete MyFile"

Apache Subversion - Principal concepts and her Architecture

Apache Subversion is an open source version control system. Founded in 2000 and Its development is still ongoing in fact the latest releases (1.8.18 and 1.9.6) were delivered in July (current year).

Principal concepts of Subversion

A best practice of Subversion expects to manage the source code using three main directories: trunk, branches and tags.

• The "trunk" would be the main body of development, originating from the start of the project until the present.

• The "branches" directory contains all branches. A branch will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.

• The "tags" directory, as branches, contains all tags. A tag will be a point in time on the trunk or a branch that you wish to preserve. The two main reasons for preservation would be that either this is a major release of the software, whether alpha, beta, RC or RTM, or this is the most stable point of the software before major revisions on the trunk were applied.

Branch and tag management

A branch or a tag can be created with svn copy command.  A tag is just a “snapshot” of a project in time. Create a new tag when a software is deliverd represent a best practice. Instead a branch can have one of the following purposes:

• feature branch: This type of branch is usually created from the trunk or an other branch. The goal of the usage a feature branch is that to develop a new feature but at the risk of instability during the development, then the use of this branch is useful to maintain a stable trunk or branch where the feature branch was created.
• maintenance branch: this type of branch is usally created from a tag so because the development of this branch starts from a stable point (best practice). The scope is the bug fixing or the development of a precise subset of features. 

A merge operation is to bring changes from a branch to another branch (or trunk). A feature branch is always merged in starting code line (branch or trunk). Instead about the maintenance branch, almost always it is merged on the trunk, the vice versa depends on the cases.

The following picture shows an example of what is described now:

Branch and Tag management

Subversion Architecture

The Subversion Architecture is modular in fact it is composed of more software modules. The pricipal modules are:

• The CLI (command line client app) and UI Clients (as tortoisesvn) are the clients where an user (as a developer, devOps, etc...) interacts with Subversion system.
• Client Library provides the interfaces used by clients.
• Working Copy Management Library collects and manages all features about the interactions between local copies and central repository.
• Repository Acces (RA): between Client Library and repository  are multiple routes through a RA layer, some of which go across computer networks and through network servers which then access the repository, others of which bypass the network altogether and access the repository directly.
• Apache HTTP Server: It contains a plug-in module, used to make your repository available to others over a network.
• svnserve: A custom standalone server program, runnable as a daemon process or invokable by SSH; another way to make your repository available to others over a networ.
• Subversion Repository, Berkeley DB and FSFS are used to storage systems. 

The following diagram illustrates an overview of Subversion architecture.

Subversion's Architecture

External Links

1. Apache Subversion - Official Page

Security Management in Subversion

Subversion provides the management of user, group and permissions. They are two files authz and passwd in svn/repos/<repository_name>/conf. In the passwd file you need to add some usernames and passwords. Instead the authz file manages the groups and permissions.

How to add a new user

Edit the passwd file and append a new user with password under [users] section.
Example: 

Add a new user with "newuser" as username and "passw0rd@" as password.

[users]
myuser=password!
newuser=passw0rd@

How to assign an user to a group

Edit authz file and update the [groups] section.
Example:
Add newuser in "developers" group.

[groups]
guests = myuser
developers = myuser

How to assign the grants to a group

The grants are configurated in authz file, the path into repo is enclosed in square brackets.
For example, we want to give read permissions to guests group and write and read to developers groups then you can use the following configuration:

[/myrepo]
@guests = r
[/myrepo]
@developers = rw

As just shown is just the basic management indicated for a small repository. Fortunately, for managing large repositories, various security management tools are available as "SVN Access Manager".