Releases
Current version
Git/Latestdiff: 1.5.6
Latest Snapshots
Produced after each commit or rebase to new upstream version
GIT clone e.g. at git://git.rsbac.org/linux-6.18.y
Events
No events planned
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| documentation:svn [2006/05/02 13:40] – (old revision restored) 127.0.0.1 | documentation:svn [2006/06/02 11:03] (current) – removed kang | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | //If you want to add code for RSBAC, you probably also want to read [[documentation: | ||
| - | \\ | ||
| - | ===== The RSBAC SVN structure ===== | ||
| - | // 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 | ||
| - | </ | ||
| - | |||
| - | ==== 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 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 " | ||
| - | |||
| - | * 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. | ||
| - | |||
| - | ===== Working with SVN ===== | ||
| - | === So, how do I checkout the latest linux-rsbac kernel ? === | ||
| - | |||
| - | < | ||
| - | # mkdir ~/ | ||
| - | # cd ~/ | ||
| - | </ | ||
| - | |||
| - | Be sure to replace " | ||
| - | |||
| - | //For anonymous checkout// | ||
| - | < | ||
| - | # svn checkout svn:// | ||
| - | branches/ | ||
| - | </ | ||
| - | |||
| - | //For developpers with write access// | ||
| - | < | ||
| - | # svn checkout svn+ssh://< | ||
| - | subversion/ | ||
| - | </ | ||
| - | |||
| - | === Great, what about comitting, updating, etc ? === | ||
| - | |||
| - | 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, | ||
| - | < | ||
| - | # 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. | ||
| - | |||
| - | |||
| - | === Ok, I will take extreme care. What about diffing and creating patches ? === | ||
| - | |||
| - | Simple, this will show you differences: | ||
| - | < | ||
| - | # svn diff linux-kernel/ | ||
| - | </ | ||
| - | |||
| - | Alternatively, | ||
| - | < | ||
| - | # svn diff --diff-cmd=$(which svn-diff) linux-kernel/ | ||
| - | linux-kernel/ | ||
| - | </ | ||
| - | |||
| - | If you want to overring diffing settings and use the " | ||
| - | < | ||
| - | [helpers] | ||
| - | diff-cmd = / | ||
| - | </ | ||
| - | |||
| - | === How to I create a tagged version ? === | ||
| - | |||
| - | Nothing simpler either: | ||
| - | < | ||
| - | # svn copy linux-kernel/ | ||
| - | </ | ||
| - | Do not ever touch again tagged versions. These *will* stay this way. | ||
| - | When doing a bugfix, create a new tag from this one. | ||
| - | |||
| - | === Ok, a new version of the Linux kernel has been uploaded to trunk. How do I merge it into linux-rsbac branch ? === | ||
| - | |||
| - | Here we go again: | ||
| - | |||
| - | |||
| - | * Replace < | ||
| - | * Replace < | ||
| - | |||
| - | < | ||
| - | # cd linux-kernel/ | ||
| - | # svn merge -r < | ||
| - | </ | ||
| - | |||
| - | 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 :-) | ||
| - | |||
| - | |||
| - | === I use my SVN tree to build the kernel and I don't want SVN to care about all the files it creates ! === | ||
| - | |||
| - | < | ||
| - | # cd /tmp | ||
| - | # wget http:// | ||
| - | # cd ~/ | ||
| - | # svn propset svn:ignore -R -F / | ||
| - | # svn commit -m "Added svn:ignore properties." | ||
| - | </ | ||
| - | |||
| - | === Speeding up svn+ssh access === | ||
| - | |||
| - | 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 " | ||
| - | |||
| - | 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 ~/ | ||
| - | </ | ||
| - | |||
| - | 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 ! | ||