Version 8 (modified by nicolasmartin, 23 months ago) (diff)

Good Practices

Last edition on 10/21/19 17:57:09 by smueller

Set up a proper development environment once and for all

Obviously each developer can have its own working approach for developing the NEMO code, however we recommend to download and run this script to install a clean and minimal working copy with everything you need to start your development and to support the NEMO reference.
Actually it will download from the SVN repository a working copy of the NEMO root directory but only in terms of the very first paths in depth, you will have NEMO/branches and NEMO/releases with empty subfolders. Only the trunk (NEMO/trunk) and the last NEMO release (NEMO/releases/release-X.X) will be entirely downloaded.

The benefits of this new way are numerous:

  • Possibility to work offline like git: create a dev branch by copying the trunk and start coding without a first commit to the repository
  • Simple SVN commands (UNIX-like) without tedious svn+ssh URL scheme: create your dev branch locally and commit it as you want to the repository instead of creating the dev branch remotely on the repository and then downloading it to start working.
  • Put an end at the branches scattering, no more multiple working copies but now all needed developments handled in one location

Use the robust syntax to refer to a specific SVN revision

With the new layout of the repository, some may encounter downloading or updating issues with the following syntax "-r REV URL".
Use instead the more robust syntax 'URL@REV'

See ​http://svnbook.red-bean.com/en/1.7/svn.advanced.REVs.html for more.

Manage SVN external references according to your needs

As of now, the working copy of the NEMO code is build from several sources in the repository, via SVN external definitions.
The "core" code which is actively developed in line with NEMO releases is still present and unique to a selected branch. Whereas the "complementary" code modified from time to time between consecutive releases has been extracted from the development organisation to be shared between branches from one location.

Here is the current list of these externals definitions for the NEMO code

Wiki page "Developers/ExternalDefinitions" does not exist

From that you have 2 options per external, either

  • you want to be isolated by default from unwanted commits coming from outside, fix a revision for the definition (add @ with revision number at the end of relative path) and you will be in safe mode.
  • you want to be able to commit on this external from your dev branch, don't set a revision on the definition but you will receive its commits at each SVN update.

Of course you can change your mind any time and update the externals of your branch on a case-by-case basis. But don't forget to push your modified externals to the repository.

Regarding the main branches for NEMO development, the default configuration for the externals will be as follows:
Releases will have all externals fixed with revisions whereas trunk will be free of revisions.

Usual commands for major steps of a development branch

Wiki page "Developers/UsualCommands" does not exist

Be smart while working with ticket

Be careful if you combine the 2 cases

If a commit is related to ticket(s), we highly suggest to add the commit message as a comment in related ticket(s). To do so, you can use a word from this list addresses re references refs see followed by usual ticket links).
Ex: write see #1948 somewhere in the commit message to link with #1948

If a commit is a fix, you can close targeted ticket(s) with the commit. To do so, you can use one of the word in the list close closed closes fix fixed fixes followed by usual ticket link(s).
Ex: write fix #1948 somewhere in the commit message to close #1948 without a browser.