| 11 | | == Getting a copy of the BOINC source == |
| 12 | | |
| 13 | | The BOINC source code is stored in a [http://www.git-scm.com Git] repository. |
| 14 | | To get the source code on Unix: |
| 15 | | {{{ |
| 16 | | git clone git://boinc.berkeley.edu/boinc-v2.git boinc |
| 17 | | or |
| 18 | | git clone http://boinc.berkeley.edu/git/boinc-v2.git boinc |
| 19 | | }}} |
| 20 | | |
| 21 | | This will give you a copy that you can modify locally, |
| 22 | | but not push changes to the BOINC repository. |
| 23 | | For write access, see below. |
| 24 | | |
| 25 | | On Windows, you'll need a Git client such as !TortoiseGit (see below). |
| 26 | | Right-click on the parent directory, select 'Git Clone...', |
| 27 | | and fill in the dialog with one of the above URLs. Don't forget |
| 28 | | to remove both 'git clone' and 'boinc' from the commands above. |
| 29 | | |
| 30 | | == Branches == |
| 31 | | |
| 32 | | Various versions of the code are available at any given point: |
| 33 | | |
| 34 | | === Development === |
| 35 | | |
| 36 | | The '''master''' branch contains the latest source code for all components of BOINC. |
| 37 | | It is always under development, and has not necessarily been thoroughly tested. |
| 38 | | |
| 39 | | To checkout the '''master''' branch: |
| 40 | | {{{ |
| 41 | | git checkout master |
| 42 | | }}} |
| 43 | | |
| 44 | | === Client releases === |
| 45 | | |
| 46 | | The client software (client and manager) is maintained as follows: |
| 47 | | |
| 48 | | * The code for each release is 'tagged'. |
| 49 | | For example, the code for version 6.3.14 is tagged with '''client_release_6_3_14'''. |
| 50 | | * A 'branch' is created for each released minor version. |
| 51 | | For example, the branch '''client_release_6_2''' is the code for the latest release of version 6.2. |
| 52 | | |
| 53 | | To checkout the '''client_release_6_12''' branch: |
| 54 | | {{{ |
| 55 | | git checkout client_release_6_12 |
| 56 | | }}} |
| 57 | | |
| 58 | | === Server releases === |
| 59 | | |
| 60 | | For all software other than the client (i.e., server, web, and API) |
| 61 | | a "stable" version is kept in a branch, '''server_stable'''. |
| 62 | | Don't use the server software in a client tag or branch; it probably isn't stable. |
| 63 | | |
| 64 | | Notes: |
| 65 | | * There is no formal testing process for server software. |
| 66 | | Every so often, when no bugs have been reported recently, |
| 67 | | we merge the '''master''' branch into '''server_stable'''. |
| 68 | | * Because of limited resources, bug fixes to server software are normally |
| 69 | | NOT back-ported from '''master''' to '''server_stable'''. |
| 70 | | |
| 71 | | For these reasons: '''the master branch is typically a better choice |
| 72 | | than server_stable for server software'''. |
| 73 | | |
| 74 | | |
| 100 | | |
| 101 | | == Write access to the main repository == |
| | 32 | == Getting a copy of the BOINC source == |
| | 33 | |
| | 34 | To clone the BOINC Git repository into a local directory called (for example) 'boinc_repo', run: |
| | 35 | |
| | 36 | {{{ |
| | 37 | git clone git://boinc.berkeley.edu/boinc-v2.git boinc_repo |
| | 38 | }}} |
| | 39 | or |
| | 40 | {{{ |
| | 41 | git clone http://boinc.berkeley.edu/git/boinc-v2.git boinc_repo |
| | 42 | }}} |
| | 43 | |
| | 44 | This will give you a full copy that you can modify and compile locally, but you will not be able to push changes to the BOINC repository. For write access, see further below. |
| | 45 | |
| | 46 | If you change to the newly created directory 'boinc_repo', you will see a local copy of the BOINC source code tree. |
| | 47 | These are the files corresponding to the 'remote master branch', the bleeding edge of development. |
| | 48 | Running `git status` will show that this is actually true: |
| | 49 | |
| | 50 | {{{ |
| | 51 | $ cd boinc_repo |
| | 52 | $ git status |
| | 53 | # On branch master |
| | 54 | nothing to commit, working directory clean |
| | 55 | }}} |
| | 56 | |
| | 57 | You can replace the files on your 'master branch' by files from older branches or older tags using the appropriate git command - without |
| | 58 | needing to contact the Git repository server again. This is called 'checking out'. The information to make your local copy of the Git repository a fully navigable development history is tucked away under the '.git' subdirectory. |
| | 59 | |
| | 60 | On Windows, you'll need a Git client such as !TortoiseGit (see below). |
| | 61 | Right-click on the parent directory, select 'Git Clone...', and fill in the dialog with one of the above URLs. Don't forget to remove both 'git clone' and 'boinc' from the commands above. |
| | 62 | |
| | 63 | == Tags & Branches == |
| | 64 | |
| | 65 | Various versions of the source code are available in the remote repository (and now, in your local copy of it): |
| | 66 | |
| | 67 | * '''remote tags''': |
| | 68 | These are snapshots of the state of development taken at a specific point in time. You can check out a 'remote tag', but you should not modify the files thus checked out - for that you need a separate branch (which can be created later though). |
| | 69 | The tag's name indicates what's in there. For example, the release of BOINC client version 7.0.60 has been given then tag 'client_release/7.0/7.0.60'. |
| | 70 | Run `git tag` to list the remote tags. |
| | 71 | * '''remote branches''': |
| | 72 | BOINC developers perform long-running work on source code that needs to be visible to other members of the team by working on a 'remote branch'. There are: |
| | 73 | * The '''remote master branch''': This is the most recent version of the source code. It always exists, contains the freshest code and has not necessarily been thoroughly tested. |
| | 74 | * '''Other branches''': For example, work on version 6.12 of BOINC that is not done in the 'remote master branch', for example due to the need to apply an urgent fix may be done in a remote branch called 'client_release/6/6.12'. |
| | 75 | Run `git remote show origin` to list the remote branches. |
| | 76 | |
| | 77 | As you cloned the Git repository, a 'local master branch' was created. This initially corresponds to the 'remote master branch', but once you start editing files, it will evidently deviate from it. |
| | 78 | |
| | 79 | You can create local branches and tags (both invisible to anyone but yourself). You can check out a specific 'remote tag' to compile, or you can create a local branch based on a specific 'remote tag' to work on the code. |
| | 80 | |
| | 81 | * See [http://git-scm.com/book/en/Git-Basics-Tagging Git Basics - Tagging] for the concept of 'tagging'. |
| | 82 | * See [http://git-scm.com/book/en/Git-Branching-Remote-Branches Git Branching - Remote Branches] for the concept of 'remote branches' and the concepts of the 'local' and 'remote' master branches. |
| | 83 | * See [http://stackoverflow.com/questions/1457103/what-is-the-difference-between-a-tag-and-a-branch-in-git What is the difference between a tag and a branch in git?] for a short intro on 'tags' and 'branches'. |
| | 84 | * See [http://stackoverflow.com/questions/5582208/checkout-git-tag Checkout GIT tag] for an explanation about 'checking out git tags'. |
| | 85 | |
| | 86 | === Development on the bleeding edge === |
| | 87 | |
| | 88 | If you want to work on the remote 'master' branch, check it out locally: |
| | 89 | |
| | 90 | {{{ |
| | 91 | git checkout master |
| | 92 | }}} |
| | 93 | |
| | 94 | Actually this has already happened when you cloned the repository, so the above command is mainly useful if you want to go back to the remote master branch after you modified some files in a hasty fashion. |
| | 95 | |
| | 96 | === Check out a specific tag for compilation === |
| | 97 | |
| | 98 | As said above, the code for each release is 'tagged'. For example, the code for version 7.0.65 is tagged with `client_release/7.0/7.0.65`. |
| | 99 | |
| | 100 | Run |
| | 101 | {{{ |
| | 102 | git tag |
| | 103 | }}} |
| | 104 | to list all the visible tags. |
| | 105 | |
| | 106 | Run |
| | 107 | {{{ |
| | 108 | git tag --list '*/7.0/*' |
| | 109 | }}} |
| | 110 | to list only the tags matching '/7.0/'. |
| | 111 | |
| | 112 | Run |
| | 113 | {{{ |
| | 114 | git checkout client_release/7.0/7.0.65; git status |
| | 115 | }}} |
| | 116 | to check out BOINC client version 7.0.65. |
| | 117 | |
| | 118 | ...and proceed with compilation. |
| | 119 | |
| | 120 | == Server releases == |
| | 121 | |
| | 122 | For all software other than the client (i.e., server, web, and API) |
| | 123 | a "stable" version is kept in a branch, '''server_release'''. |
| | 124 | Don't use the server software in a client tag or branch; it probably isn't stable. |
| | 125 | |
| | 126 | Run |
| | 127 | |
| | 128 | {{{ |
| | 129 | git tag --list 'server_release*' |
| | 130 | }}} |
| | 131 | |
| | 132 | to list the available tags for stable server releases. |
| | 133 | |
| | 134 | Notes: |
| | 135 | |
| | 136 | * There is no formal testing process for server software. Every so often, when no bugs have been reported for some time, we tag the '''master''' branch to '''server_release'''. |
| | 137 | * Because of limited resources, bug fixes to server software are normally NOT back-ported from '''master''' to '''server_release'''. |
| | 138 | |
| | 139 | For these reasons: '''the master branch is typically a better choice than server_release for server software''' (should this not be the reverse?? .ed) |
| | 140 | |
| | 141 | == Write Access to the Git Repository == |
