close Warning: Error with navigation contributor "AccountModule"

Changes between Version 20 and Version 21 of SourceCodeRepository

Aug 31, 2015, 8:09:42 PM (3 years ago)

Update to describe working with Git and new lighter-weight policies


  • SourceCodeRepository

    v20 v21  
    11= Box Backup Source Code Repository =
    3 All source code is held in Subversion with public read (but not write) access. You must [ install the Subversion client] in order to download one of the development versions listed on this page.
     3All source code is held on Github with public read (but not write) access. You can [ download the source as a ZIP file] without installing anything, or [ install a Git client] if you wish to contribute changes back to the project.
    5 The repository location is
     5The [ master repository is on GitHub].
    77== Testing the Latest Version ==
    9 If you experience a problem, and a developer checks in a fix, or additional debugging code to help diagnose it, they may ask you to try building and running the latest trunk version. To do this, you will need to:
     9If you experience a problem, and a developer checks in a fix, or additional debugging code to help diagnose it, they may ask you to try building and running the latest trunk version. The easiest way to do this is:
    11  * Install a subversion client for your distribution, or if you can't find one, [ get it from here].
    12  * Run this command to download the trunk version:
    13    {{{svn co}}}
    14  * Change into the directory `trunk`
    15  * Follow the instructions under [wiki:SourceCodeRepository#ToBuildFromtheSubversionRepository To Build From the Subversion Repository] below.
     11 * [ Download the source as a ZIP file] and extract it.
     12 * Change into the directory `boxbackup-master`
     13 * Follow the instructions under [wiki:SourceCodeRepository#ToBuildFromtheGitRepository To Build From the Git Repository] below.
    1614 * Temporarily stop any existing `bbackupd` and `bbstored` processes.
    1715 * Run the command `release/bin/bbackupd/bbackupd` or `release/bin/bbstored/bbstored`, depending if you are working on the client or the server.
    2119== Examples ==
    23 To get a list of committed changes (which may be terse), use this command:
     21To get a local editable copy of the source code, install a Git command-line client and use this command:
    25 svn log
    26 }}}
    27 To checkout the latest development version (trunk), cd to your working directory, and then use this command:
    28 {{{
    29 svn co
    30 }}}
    31 If you are updating a previous working copy of Box Backup, cd to that same working directory, and then use this command:
    32 {{{
    33 svn update
    34 }}}
    35 However, if you are __switching__ your working copy from the old repo, then the command goes like so:
    36 {{{
    37 svn switch
     23git clone
    40 Branches or the repository root can be accessed by modifying the URL.
     26Once you have done that:
    42 == To Build From the Subversion Repository ==
     28To get a [ list of committed changes] (which may be terse), run:
     30git log
     33To update your copy to the latest version, run:
     35git pull
     38Git is widely used but not especially friendly, so there is a lot of [ good documentation] available. If you are not familiar with Git, you are advised to read it. If you have problems or questions, please ask for help on the [wiki:MailingLists mailing list], and we will be happy to help.
     40== To Build From the Git Repository ==
    4442Currently you need ''autoconf'' and ''automake'' installed. Build like so:
    49 In case you are using MingW under Windows, you should use the following commands:
    50 {{{
    51 ./bootstrap && ./infrastructure/mingw/ && make && echo "Finished."
    52 }}}
     47If you are compiling on Windows, run the `bootstrap` command and then follow the [wiki:CompilationOnWindows Windows compilation instructions].
    5449If you have any error messages, or the last line of output doesn't say `Finished`, please [wiki:MailingLists contact us for help].
    8378In order to maintain structure for the Box Backup repository the following layout is used for holding all work.
    85 === Main Branch: trunk ===
     80=== Main Branch: master ===
    87 Location:
     82Web interface:
    89 This is the main branch within SVN which always works towards the next release. You should not develop directly on this branch but work on various other branches aimed at the work which is underway. Once agreed with the team then any changes are merged into this branch for any uncoming release.
    91 It is acceptable to commit bug fixes and other small changes directly to trunk so long as there is consensus on the change. But please note: this branch should compile and work at all times.
     84This is the main branch within Git which always works towards the next release. You should not develop directly on this branch but work on various other branches aimed at the work which is underway. See the [#Workflow Workflow section] below.
    9386=== Release Branches ===
    95 Location: [<version>]
    97 When an official release is made it is tagged by copying it into this directory and renaming it to the version number. If for any reason the release is remade the copy will be updated. No commits should ever be made directly to the release copies.
     88When an official release is made we will [ create a Release] on GitHub with a new (higher) version number.
    9990'''DISCUSS: Release maintenance branches??'''
    10192 * Ben: Could we take the lazy approach of asking users to use the latest version?
    103 === Snapshots ===
     94=== Development Branches ===
    105 Location: [<version>]
    107 Monthly snapshots of the development code in [source:box/trunk trunk] are created here. Information on the snapshots is available on the [wiki:Snapshots Snapshots] page.
    109 === Feature Branches ===
    111 Location: [<feature-name>]
    113 This directory holds branches dedicated to the development of specific new features. There will be one branch here for each significant new feature being worked on. The branches here will be short lived, when a feature is complete and merged into trunk they will be removed.
    115 Before committing onto one of these branches obtain agreement from the developers working on that feature. These branches may or may not compile and run at any given time, as the relevant developers wish.
    117 The definition of feature here is quite loose - a new platform port would be considered a new feature and would belong here. Current feature branches are:
    118  * '''Win32 branch''':
    119   * This branch is intended for all work required to complete the Win32 port of Box Backup. Once the port is fully complete and merged this branch will be removed.
    121 === Personal Branches ===
    123 Location: [<username>]
    125 For any experimental work, complicated bug fixes, small new features, or anything else you want at all, you are welcome to have your own private branches. Changes in a personal branch can be merged into one of the other branches with the agreement of those concerned.
    127 Developers' branches are personal, not private. You should feel free to compile, test, and run changes developers are working on, they are very likely to be happy for the feedback. But note that nothing is guaranteed and they may not compile at all, even on the developer's favourite platform.
    129 A developer is free to have just one branch of their name, or make as many branches under their directory as they see fit, within reason.
     96All developers should work on unique branches, either in the main repository (if they have write access) or on their own forks. They should submit pull requests to merge their branches. Pull requests are likely to be merged automatically if tests pass.
    13198== Workflow ==
    133 === Bug Fix ===
    135 Commit to trunk if obviously correct. Otherwise either send a patch to the -dev mailing list or use a personal branch for review.
    137 === New Feature ===
    139 Create a feature branch. As soon as possible, get changes merged into trunk after review by other developers.
    141 Changes should be incremental, but not trivial, and not break anything. If the changes are too small, then the reviews are too frequent and it becomes difficult to keep everything relevant in mind. If the changes are too large, then the review is too arduous to be completed in a timely manner by volunteer developers.
    143 === Tests ===
    145 No test code may be deleted. Test code should only be modified if completely unavoidable.
     100If you have a new feature or bug fix to submit, please [ fork the repository] to your own GitHub account, check out your copy, create a branch, commit your changes to it, and [ submit a pull request].
    147102== Formal Release Procedure ==
     104What follows is the old formal release policy. I intend to move to user-driven rolling releases, so releases in future are likely to be less well tested than this.
    149106When a release is formally made the following procedure should be followed to ensure quality releases are maintained.
    158115 1. Backup of changed files and restore of
    159116 1. Confirmation of successful compilation and all unit tests pass on all support platforms. [Some unit tests failures may be allowed if they are well understood and harmless.]
    161 == Further Information ==
    163 The Subversion home page is
    165 The Subversion manual is