Changes between Version 11 and Version 12 of UfoRevisionControl


Ignore:
Timestamp:
Jul 30, 2012, 8:32:54 AM (12 years ago)
Author:
Matthias Vogelgesang
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • UfoRevisionControl

    v11 v12  
    11= UFO Revision Control =
    22
    3 Bazaar is an official revision control system for UFO.
    4  * [http://bazaar.canonical.com/en/ Bazaar Official Web Site]
    5  * [http://doc.bazaar.canonical.com/bzr.2.2/en/ Bazaar Official Documentation]
     3Two distributed revision control systems are currently in use for the UFO project:
    64
    7 [[BR]]
    8 
    9 = Accessing Repositories =
    10 To get access to the bazaar repositories, please, create a ticket and attach your public SSH key. When access is granted, you
    11 can get the source out of the repository using following command:
    12 {{{
    13 bzr branch bzr+ssh://user@ufo.kit.edu/repo/branch
    14 }}}
    15 For example, to get the latest revision of PyHST from main tree, issue:
    16 {{{
    17 bzr branch bzr+ssh://user@ufo.kit.edu/pyhst/pyhst
    18 }}}
    19 If you'll prefer the version maintained by Matthias, issue:
    20 {{{
    21 bzr branch bzr+ssh://user@ufo.kit.edu/vogelgesang/pyhst
    22 }}}
    23 Read-only access (all repositories are only accessible from IPE and ISS networks, all other networks are restricted to selected public repositories):
    24 {{{
    25 bzr branch http://ufo.kit.edu/sources/pyhst/pyhst/
    26 }}}
    27 
    28 == Committing changes ==
    29 
    30 Any changes that you make, are ''locally'' stored with the commit command
    31 {{{
    32 bzr commit
    33 }}}
    34 which asks you for a commit message.
    35 
    36 Similar to Git, Bazaar handles the very first line of a commit message in a
    37 special way. For example `bzr log --line` prints the whole log with revision number,
    38 author, date and first line. To keep things nice and tidy, this first line
    39 should ''summarize'' the commit in ''50'' characters or less. To increase
    40 readability of these lines you may use the `<prefix>: <description>` format,
    41 with the following possible prefixes:
    42 
    43 * Fix (e.g. `Fix: segmentation fault` or `Fix: bug #1234`)
    44 * Add (e.g. `Add: web interface`)
    45 * Update (e.g. `Update: version`)
    46 
    47 Because, this line is limited to only 50 characters, you can use several
    48 paragraphs divided by newlines to explain not only ''what'' you did, but more
    49 importantly ''why'' you changed something. These paragraphs must be wrapped
    50 at 72 characters.
    51 
    52 You should definately make use of Bazaar's builtin bug-tracker support. To
    53 enable this for the UFO project add this line to your `bazaar.conf` (located in
    54 `~/.bazaar`):
    55 
    56 {{{
    57 [DEFAULT]
    58 trac_ufo_url = http://ufo.kit.edu/ufo
    59 }}}
    60 
    61 Now, for each bug that has an associated ticket, you can mark the fixing commit
    62 with
    63 {{{
    64 bzr commit --fixes ufo:123
    65 }}}
    66 
    67 [[BR]]
    68 
    69 = Public Repositories =
    70 ||= Repository =||= Description =||
    71 || framework    || The stable version of UFO framework and support libraries. New versions are only accepted after thorough testing/code review. ||
    72 || cmake        || CMake scripts to detect libraries you are maintaining. ||
    73 || opencl       || Various CMake libraries required for UFO filters. ||
    74 || <user_name>  || Development branches of all UFO related code belonging to the ''user_name''. ||
    75 
    76 [[BR]]
    77 
    78 = Publishing Source =
    79 All the source code should first go to the user private repository. The repository is created with following command:
    80 {{{
    81   bzr init-repo bzr+ssh://user_name@ufo.kit.edu/user_name/
    82 }}}
    83 The created repository will be only writable by its creator, but readable by all members of UFO project. The new repository will not automatically appear in Trac. It should be first added through the Trac configuration page. If you don't have administrative rights, you need to create a ticket.
    84 
    85 Then, the branches are created as follows (new branches will immediately appear in Trac):
    86 {{{
    87   bzr init bzr+ssh://user_name@ufo.kit.edu/user_name/branch1
    88 }}}
    89 
    90 After branch initialization you can create local repository. Just call 'bzr init' in root of the source folder. Files can be added with `bzr add` command and revision can be commited with `bzr commit -m some_comment`.
    91 This will work with local repository on your desktop computer. To submit a revision to the server, for public use, please issue:
    92 {{{
    93   bzr push bzr+ssh://user_name@ufo.kit.edu/user_name/branch1
    94 }}}
    95 
    96 Alternatively, it is possible to instruct bazaar to synchronize with the server after each commit. Just bind the local branch with the server using the following command:
    97 {{{
    98   bzr bind bzr+ssh://user_name@ufo.kit.edu/user_name/branch1
    99 }}}
    100 
    101 
    102 
    103 [[BR]]
    104 
    105 = Publishing stable versions =
    106 After through testing, the maintainers of UFO subpackages can publish them in UFO main repository. It is
    107 accessible with the following bazaar URL:
    108 {{{
    109   bzr+ssh://user@ufo.kit.edu/framework
    110 }}}
    111 
    112 You can create new branches with the following command. These branches will be writable by creator only, but accessible for everybody else. Changes to these branches will immediately appear in the Trac [http://ufo.kit.edu/ufo/browser source browser].
    113 {{{
    114   bzr init bzr+ssh://user@ufo.kit.edu/framework/branch1
    115 }}}
    116 
    117 [[BR]]
    118 
    119 = Possible workflow =
    120 
    121 There are already very good branching [http://nvie.com/posts/a-successful-git-branching-model/ models] out there. Although it's up to everyone how he will work on his personal branches, I will show how I use Bazaar to ease my life.
    122 
    123 First of all, I import some of the written code using the steps written above.
    124 {{{
    125 cd project-dir
    126 bzr init .
    127 bzr add *
    128 bzr commit
    129 bzr init bzr+ssh://user@ufo.kit.edu/user/project
    130 bzr push bzr+ssh://user@ufo.kit.edu/user/project
    131 }}}
    132 
    133 Then I clean the project directory and clone the committed code as a named branch and bind to the server:
    134 {{{
    135 rm -rf *
    136 bzr clone bzr+ssh://user@ufo.kit.edu/user/project upstream
    137 cd upstream
    138 bzr bind bzr+ssh://user@ufo.kit.edu/user/project
    139 }}}
    140 I ''never'' work directly in the upstream branch because every commit would be visible immediatly. Therefore, I branch from the `upstream` branch a local branch where development happens:
    141 {{{
    142 cd ..
    143 bzr clone upstream/ local
    144 }}}
    145 Whenever I need to work on the same project but tackling different problems, I branch from the `local` branch to a feature specific branch. To push my changes, I just pull (no merging needed) the changes from the `local` branch into the `upstream` branch
    146 {{{
    147 cd upstream
    148 bzr pull ../local
    149 }}}
    150 
    151 In the future we should streamline the development process as shown in the blog post: There are named branches with specific purposes, which may or may not branch from each other in order to form a coherent system. The two main branches are `master` where one commit means a release of the product and `develop` where actual development happens. `develop` branches from `master` and from there everyone in the personal branches. Release and feature branches are tempory branches to aid in preparing the release and to help organizing the development of new features. They are deleted when changes in these branches are merged back to `master` and `develop` respectively.
    152 
    153 The complete system can be seen in the following illustration:
    154 
    155 [[Image(branch-model.png)]]
     5* [wiki:UfoRevisionControlGit Git] for public repositories and anything that a project owner likes to have version controlled with Git. Public repositories can be browsed on http://ufo.kit.edu/repos/.
     6* [wiki:UfoRevisionControlBzr Bazaar] for internal and older, abandoned projects. All Bazaar repositories can be browsed with the [http://ufo.kit.edu/ufo/browser Source] tab in the top menu.