= Good Practices Last edition on '''[[Wikinfo(changed_ts)]]''' by '''[[Wikinfo(changed_by)]]''' [[PageOutline(2, , inline, unnumbered)]] == 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 [source:/utils/dev/install_dev_env.sh 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 [http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html 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 [[Include(wiki:Developers/GoodPractices/ExternalDefinitions)]] 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.''' == Be smart while working with ticket {{{#!rbox warning 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 link(s). \\ 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.