Fai subversion howto
From FAIWiki
Contents |
Anonymous access
If you simply want to check out the source code to analyze it or have a look at it.
svn co svn://svn.debian.org/svn/fai/trunk fai-source
Or read it online using Subversion web access:
See also
- Fai SVK howto for the 'distributed' version of these commands, which do not require any special accounts and are more appropriate for people who just want to add a few features here and there, and submit their patches to the mailing list for discussion and potential inclusion.
- Main_Page#getting_FAI
Developer access (contributions)
If you want to have write access to the FAI sources, because you want to contribute enhancements or fix bugs.
basic operation
- install subversion and read the subversion book online or in /usr/share/doc/subversion/book/svn-book.html - you should be familar with subversion and the use of branches before you begin to commit to the repository.
- get an alioth account
- subscribe to the linux-fai-devel mailing list and to the fai-commit mailinglist
- ask Thomas Lange to add you to the fai project on alioth
- checkout fai with svn co svn+ssh://<YOURALIOTHUSERNAME>@svn.debian.org/svn/fai/ ./fai-repository (./fai-repository will be created locally and needs 250mb hd space.)(you will have to type in your password multiple times in a row, known issue)
- create a people directory for yourself: cd fai-repository/people ; mkdir <YOURNAME>
- Depending on what you are working on, copy the fai trunk, a tag,or a branch to your people directory, e.g.:svn cp trunk/ people/<YOURUSERNAME>/my-development-branch -m "copied an example branch". Ask other fai developers if you are unsure if you should create your branch from trunk,tag or a branch.
- You can have as many branches as you need. Please add your branch(es) to the people branches wikipage !
- You must not commit to the trunk or a release branch unless you should. Thomas is the only one who may decide who should :-) If you commit accidently to trunk or a release branch, revert the changes and write an apoligy mail to the fai-devel mailinglist. If you repeatly fuck it up, your write permissions may be revoked.
- if you're low on hd space, you can now delete the ./fai-repository and checkout your branches only: svn co svn+ssh://<YOURUSERNAME>@svn.debian.org/svn/fai/people/<YOURUSERNAME> ./my-branches
- develop in your branch of fai and commit early, commit often :-). But, if possible, do the checks described in testing for your code on a regular basis.
- if you are going to fix a specific bug, which is already in the BTS, please document that in the Debian BTS.(If you fix a bug that is not yet in BTS, it's always a good idea to report it to the BTS, first :) )
special tasks
getting specific revisions
- sometimes you make mistakes and want to go back to a specific revision - this shows how to do it:
svn co -r 3246 svn+ssh://h01ger-guest@svn.debian.org/svn/fai/people/h01ger/fai-kernels ./fai-kernels-r3246
merging
- to merge multiple bugfixes into one single branch, I ran the following commands (please refer to the svnbook for detailed explanations why this is done that way):
svn cp ../../tags/r-2_8_4/ r-2_8_4-fai-cd_sarge_fixes svn merge ../../../tags/r-2_8_4@2910 ../bugfixes/320024@2968 svn ci -m "merging /tags/r-2_8_4@2910 /people/lazyboy/bugfixes/320024@2968 in here" svn merge ../../../tags/r-2_8_4@2910 ../bugfixes/334333@2968 svn ci -m "merging /tags/r-2_8_4@2910 /people/lazyboy/bugfixes/334333@2968 in here"
deleting unused branches
A bugfix branch can be deleted if the following requirements are met:
- the patch must be applied to any main branch which may need it - this is:
- the newest release branch
- maybe the branch of the package currently in Debian stable and testing
- the trunk.
At the time of this writing, the first two are the same - but that can change in the furture.
- it must be documented in the BTS where the patch can be found instead - this should be
- in a mail to the bts for the given
- a usertag (to be defined how this has to be done exactly - ask on gthe mailing list if unsure)
If these are given, a developer can be asked to delete this bugfix.
You can see bugs ordered by the usertag svn-trunk here:
Henning
