Theses are examples only !

 -- ila
    -- trunk
    -- tags
    -- branches

 -- linux-kernel
    -- 2.4
        -- trunk
        -- tags
            -- linux-rsbac-2.4.30-1.2.4
            -- linux-rsbac-2.4.31-1.2.4
            -- linux-rsbac-2.4.31-1.2.5rc1
            -- linux-rsbac-2.4.32-1.3.0
            -- linux-rsbac-2.4.32-1.3.1
        -- branches
            -- linux-rsbac
    -- 2.6
        -- trunk
        -- tags
            -- linux-rsbac-2.6.10-1.2.4
            -- linux-rsbac-2.6.11-1.2.4
            -- linux-rsbac-2.6.11-1.2.5rc1
            -- linux-rsbac-2.6.12-1.3.0
            -- linux-rsbac-2.6.12-1.3.1
        -- branches
            -- linux-rsbac
 
 -- rsbac-admin
    -- trunk
    -- tags
        -- 1.2.4
        -- 1.2.5rc1
        -- 1.3.0
    -- branches

 -- rsbac-regression
    -- trunk
    -- tags
    -- branches

People using a versioning tool like SVN use to have three separate directory per project:

• trunk is meant to be the latest and greatest, what's currently being worked on.
• tags contains every releases, they are pulled from trunk or a branch when developpers decides that its stable for a nex release. Bugfixing made for theses very stabtle releases are based on the ctags versions, not trunk.
• branches are derivation from the work being done on trunk. They share the same code but are growing quite differently.

RSBAC uses this structure for every project hosted, however, the “linux-kernel” project is a bit different:

• trunk are the versions released from kernel.org
• RSBAC versions are a in a branch from trunk, called linux-rsbac

This allow easy merging when Linux upgrades to a new version.

# mkdir ~/code/rsbac_repos/
# cd ~/code/rsbac_repos/

Be sure to replace “2.6” by “2.4” for the 2.4 kernel.

For anonymous checkout

# svn checkout svn://rsbac.org/rsbac1/linux-kernel/2.6/\
branches/linux-rsbac

For developpers with write access

# svn checkout svn+ssh://<you@>rsbac.org/daten/\
subversion/rsbac1/linux-kernel/2.6/branches/linux-rsbac

Be sure to always update the repository before doing anything:

# svn update

Check what you are gonna commit, if you want to make sure:

# svn status

Check commit the actual thing:

# svn commit

A list of the modified file will be presented to you. Check that you modified only what you wanted. Do not make a commit for every next file, but for a set of changes instead. Make sure to write a comment about what you did (e.g.: Added feature XXX. Fixed Mantis Bug #3840). If you do not, we will get you and kill you

Alternatively, you can specify the comment directly on the command line:

# svn commit -c "kang: Added feature XXX. This fixes Mantis bug #3840"

Never commit something “just to test” or break something intentionally in the tree.

Try to make one commit per set of features.

Simple, this will show you differences:

# svn diff linux-kernel/2.6/trunk linux-kernel/2.6/branches/linux-rsbac

Alternatively, this will create a nice and ready to use patch (make sure you have svn-diff installed!):

# svn diff --diff-cmd=$(which svn-diff) linux-kernel/2.6/trunk\
linux-kernel/2.6/branches/linux-rsbac

If you want to overring diffing settings and use the “svn-diff” wrapper automatically edit your “$HOME/.subversion/config” and add the following lines (make sure of the path to the “svn-diff” binary!):

	[helpers]
	diff-cmd = /usr/bin/svn-diff

Nothing simpler either:

# svn copy linux-kernel/2.6/branches/linux-rsbac linux-kernel/2.6/tags/linux-rsbac-2.4.31-1.2.5rc2

Do not ever touch again tagged versions. These *will* stay this way. When doing a bugfix, create a new tag from this one.

Here we go again:

• Replace <first> by the old svn revision of the trunk
• Replace <last> by the new svn revision of the trunk

# cd linux-kernel/2.6/linux-rsbac
# svn merge -r <first>:<last> linux-kernel/2.6/trunk

SVN will merge everything for you and show the conflicts. Fix them and commit.. Here you are, you upgraded the branch to the new Linux kernel version

# cd /tmp
# wget http://www.moses.uklinux.net/patches/dontdiff
# cd ~/code/rsbac_repos/linux-kernel/2.6/branches/linux-rsbac
# svn propset svn:ignore -R -F /tmp/dontdiff .
# svn commit -m "Added svn:ignore properties." 

From OpenSSH 4 and forward there a new cool feature finally got merged (server side is there from 2.0) - multiplexing ssh connections. It means that you can reuse authentication principles negotiated during first connection to the server (it becomes “master” connection), efficiently using its control channel, instead of creating your own for every next connection. It really boosts logging process, because all negotating process is skipped entirelly. In real life, it makes me login to rsbac.org immidiatelly after clicking enter instead of waiting for negotiating phase to complete. And (since we are using svn via ssh) it can be used for svn access too ! Sounds cool ? Obviously, so let's get started.

Ingredients:

- OpenSSH 4.0 or later for client (ssh -V) - OpenSSH 2.0 or later for server (sshd -V)

all this requirments are met on rsbac.org svn repo.

Add the following lines into your .ssh/config

ControlMaster auto
ControlPath ~/.ssh/ssh_control_%h_%p_%r

From now on, after initiating first connection to rsbac.org with ssh -M username@server you'll get unix socket file inside .ssh which all next connections to the same server will be (re)using. Do not close master connection ! If you have nothing to do on rsbac.org (you don't ;) issue ssh -M -f user@server sleep 10000 - this way ssh will fork into background, keeping your precious master connection in up and running. No svn modification is necesary, ssh takes care about everything itself. Now you can try svn commands and see how much faster it is - you _will_ be shocked !