documentation:dev:scm:svn
=>  Releases

Current version
Git/Latestdiff: 1.5.6

Latest Snapshots
Produced after each commit or rebase to new upstream version

GIT
RSBAC source code, can be unstable sometimes

=>  Events

No events planned

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
documentation:dev:scm:svn [2006/06/02 15:14]
kang corrected a typo too
documentation:dev:scm:svn [2006/06/04 09:42]
ao Spelling
Line 1: Line 1:
-//If you want to add code for RSBAC, you maybe also want to read [[documentation:​dev:​scm:​svk|SVK]] documentation.//​ 
-\\  
- 
-===== The RSBAC SVN structure ===== 
- 
-<​code>​ 
-* Main 2.6 repository 
-  -- rsbac-2.6 
-     -- trunk 
-     -- tags 
-        -- linux-2.6.16.29-rsbac-1.2.7 
-     -- branches 
-        -- rsbac-1.2 
- -- rsbac-1.3 
- -- rsbac-1.3-replication 
- -- rsbac-1.2-virtualusers 
- 
-* Main 2.4 repository 
-  -- rsbac-2.4 
-     -- trunk 
-     -- tags 
-     -- branches 
- 
-* Administration tools 
-  -- rsbac-admin 
-     -- trunk 
-     -- tags 
-     -- branches 
- 
-* Python bindings and tools 
-  -- rsbac-python 
-     -- python-api 
-     -- pyrex 
- 
-* Apache integration 
-  -- rsbac-apache 
- 
-* Other development tools 
-  -- rsbac-misc 
-</​code>​ 
- 
-There are two more repository, ''​linux-2.6''​ and ''​linux-2.4''​ which are SVN 
-copies of the current kernel releases. They are only used for merging. 
- 
-==== What are trunk and all that ? ==== 
- 
-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 stable 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 their own way. 
- 
- 
-RSBAC uses this structure for most projects hosted. 
- 
-===== Working with SVN ===== 
-=== So, how do I checkout the latest linux-rsbac kernel ? === 
- 
-<​code>​ 
-# mkdir ~/​code/​rsbac 
-# cd ~/​code/​rsbac 
-</​code>​ 
- 
-Replace "​2.6"​ by "​2.4"​ for the 2.4 kernel. 
- 
-//For anonymous checkout// 
-<​code>​ 
-Development version: 
-# svn checkout svn://​rsbac.org/​rsbac-2.6/​trunk 
-Stable release: 
-# svn checkout svn://​rsbac.org/​rsbac-2.6/​branches/​rsbac-1.2 (or better) 
-Everything in this repository: 
-# svn checkount svn://​rsbac.org/​rsbac-2.6 
-</​code>​ 
- 
-//For developpers with write access// 
-<​code>​ 
-Development version: 
-# svn checkout svn+ssh://<​you@>​rsbac.org/​daten/​\ 
-subversion/​rsbac-2.6/​trunk 
-Stable release: 
-# svn checkout svn+ssh://<​you@>​rsbac.org/​daten \ 
-subversion/​rsbac-2.6/​branches/​rsbac-1.2 
-Everything in this repository: 
-# svn checkout svn+ssh://<​you@>​rsbac.org/​daten \ 
-subversion/​rsbac-2.6 
-</​code>​ 
- 
-=== Great, what about comitting, updating, etc ? === 
- 
-The following steps are executed from your checkout directory. 
-<​code>​ 
-# cd ~/​code/​rsbac/​trunk (or any other checkout) 
-</​code>​ 
- 
-Be sure to always update the repository before doing anything: 
-<​code>​ 
-# svn update 
-</​code>​ 
- 
-Check what you are gonna commit, if you want to make sure: 
-<​code>​ 
-# svn status 
-</​code>​ 
- 
-Commit the changes: 
-<​code>​ 
-# svn commit 
-</​code>​ 
- 
-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 message about what you did (e.g.: Added feature XXX. Fixed Mantis Bug #3840). If you do not, we will get you and kill you :-) 
-If you are applying a patch from someone, be nice and mention their 
-name/​nick/​address whatever is relevant. 
- 
-Alternatively,​ you can specify the message directly on the command line: 
-<​code>​ 
-# svn commit -c "kang: Added feature XXX. This fixes Mantis bug #3840" 
-</​code>​ 
- 
-**Never** commit something "just to test" or break something intentionally in 
-the tree. The development tree should be (as possible) always compilable and possible to 
-run. 
- 
-Again, try to make one commit per set of features. 
- 
-=== Ok, I will take extreme care. What about diffing and creating patches ? === 
- 
-You can diff in the same repository: 
-<​code>​ 
-# svn diff branches/​rsbac-1.2 tags/​linux-2.6.16.19-rsbac-1.2.7 
-</​code>​ 
- 
-If you need to create patches against the vanilla Linux kernel, use the normal 
-''​diff''​ command or install [[documentation:​dev:​scm:​svk|SVK]] 
- 
-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!): 
-<​code>​ 
- [helpers] 
- diff-cmd = /​usr/​bin/​svn-diff 
-</​code>​ 
- 
-=== How to I create a tag for a release ? === 
- 
-Really simple too: 
-<​code>​ 
-# svn copy branches/​rsbac-1.2 tags/​linux-2.6.16.19-rsbac-1.2.7 
-or 
-# svn copy trunk tags/​linux-2.6.1.19-rsbac-1.3.0pre2 
-</​code>​ 
- 
-Do not ever commit again over tagged versions. Tags should *not* be modified 
-in any way. 
-When making a bugfix release, create a new tag from this one or from another branch. 
- 
-=== I would like to merge branches === 
- 
-Here we go again: 
- 
-  * Replace <​first>​ by the old svn revision of the trunk 
-  * Replace <​last>​ by the new svn revision of the trunk 
- 
-<​code>​ 
-# cd trunk 
-# svn merge -r <​first>:<​last>​ branches/​rsbac-1.3-replication 
-</​code>​ 
- 
-SVN will merge everything for you and show the conflicts. Fix them and commit 
-:-) 
- 
-=== I use my SVN tree to build the kernel and I don't want SVN to care about all the files it creates ! === 
- 
-<​code>​ 
-# cd /tmp 
-# wget http://​www.moses.uklinux.net/​patches/​dontdiff 
-# cd ~/​code/​rsbac/​rsbac-2.6/​trunk 
-# svn propset svn:ignore -R -F /​tmp/​dontdiff . 
-# svn commit -m "Added svn:ignore properties." ​ 
-</​code>​ 
- 
-=== Speeding up svn+ssh access === 
- 
-From OpenSSH 4 and onwards 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 requirements are met on rsbac.org svn repositories. 
- 
-Add the following lines into your .ssh/config 
-<​code>​ 
-ControlMaster auto 
-ControlPath ~/​.ssh/​ssh_control_%h_%p_%r 
-</​code>​ 
- 
-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 necessary, ssh takes care about everything itself. 
-Now you can try svn commands and see how much faster it is - you __will__ be shocked ! 
  
//
documentation/dev/scm/svn.txt · Last modified: 2006/06/04 09:42 by ao

documentation/dev/scm/svn.txt · Last modified: 2006/06/04 09:42 by ao
This website is kindly hosted by m-privacy