Ignore:
Timestamp:
Jul 21, 2024, 1:47:00 PM (4 months ago)
Author:
abarral
Message:

Fix r5093: ship new fcm source

File:
1 edited

Legend:

Unmodified
Added
Removed

  • LMDZ6/branches/Amaury_dev/tools/fcm/doc/collaboration/index.html

    r1578 r5094  
    1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    2 
     1<!DOCTYPE html>
    32<html>
    43<head>
    5   <title>External Distribution &amp; Collaboration for FCM Projects</title>
    6   <meta name="author" content="FCM development team">
    7   <meta name="descriptions" content=
    8   "External Distribution &amp; Collaboration">
    9   <meta name="keywords" content="FCM, distribution, collaboration">
    10   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    11   <link rel="stylesheet" type="text/css" href="style.css">
     4  <title>FCM: External Distribution &amp; Collaboration for FCM Projects</title>
     5  <meta name="author" content="FCM team" />
     6  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
     7  <link rel="icon" href="../etc/fcm-icon.png" type="image/png" />
     8  <link rel="shortcut icon" href="../etc/fcm-icon.png" type="image/png" />
     9  <link href="../etc/bootstrap/css/bootstrap.min.css" rel="stylesheet" media="screen" />
     10  <link href="../etc/fcm.css" rel="stylesheet" media="screen" />
    1211</head>
    13 
    1412<body>
    15   <p align="right"><img src="logo.png" alt="Met Office logo" width="85" height=
    16   "85"></p>
    17 
    18   <h1>External Distribution &amp; Collaboration for FCM Projects</h1>
    19 
    20   <p align="center">Last updated: 28 November 2006</a>
    21 
    22   <p align="center">Met Office<br>
    23   FitzRoy Road, Exeter<br>
    24   Devon, EX1 3PB<br>
    25   United Kingdom</p>
    26 
    27   <p align="center">&copy; Crown Copyright 2006</p>
    28 
    29   <p align="center">Questions regarding this document or permissions to quote
    30   from it should be directed to the <a href=
    31   "mailto:iprmanager@metoffice.gov.uk">IPR Manager</a>.</p>
    32  
    33   <script type="text/javascript">
    34   <!--
    35   var out = 'For printing, please use the '
    36   out    += '<a href="fcm-collaboration.pdf">PDF<\/a> version of the document.'
    37   document.write ('<p align="center">')
    38   document.write (out)
    39   document.write ('<\/p>')
    40   //-->
    41   </script>
    42 
    43   <h2><a name="introduction" id="introduction">Introduction</a></h2>
     13  <div class="navbar navbar-inverse">
     14    <div class="container-fluid">
     15      <div class="navbar-header">
     16        <a class="navbar-brand" href=".."><span class="fcm-version">FCM</span></a>
     17      </div>
     18      <div class="collapse navbar-collapse">
     19        <ul class="nav navbar-nav">
     20          <li><a href="../installation/">Installation</a></li>
     21
     22          <li><a href="../user_guide/">User Guide</a></li>
     23        </ul>
     24      </div>
     25    </div>
     26  </div>
     27
     28  <div class="page-header">
     29    <div class="fcm-page-content pull-right well well-sm"></div>
     30    <h1>FCM: Distribution &amp; Collaboration for FCM Projects</h1>
     31  </div>
     32
     33  <div class="container">
     34  <div class="row">
     35  <div class="col-md-12">
     36
     37  <h2 id="introduction">Introduction</h2>
    4438
    4539  <p>This document describes how projects configured under FCM can be
    4640  distributed externally. Particular attention is given to collaborative
    4741  distributions - where the external user regularly returns code for
    48   consolidation into the central repositories which hold the master copies of the
    49   code.</p>
    50 
    51   <p><b>Note:</b> This document assumes that the repositories are inaccessible to
    52   the external user, due to issues of security and practicality.</p>
    53 
    54   <h2><a name="distribution" id="distribution">Creating a Distribution</a></h2>
     42  consolidation into the central repositories which hold the master copies of
     43  the code.</p>
     44
     45  <p><dfn>Note:</dfn> This document assumes that the repositories are
     46  inaccessible to the external user, due to issues of security and
     47  practicality.</p>
     48
     49  <h2 id="distribution">Creating a Distribution</h2>
    5550
    5651  <p>A system configured under FCM can be distributed by packaging a known
    … …  
    8984        separately. It is best if stable releases of the various systems can be
    9085        synchronised so that, for example, a VAR stable release uses code from
    91         an OPS stable release which both use code from the same GEN release.</li>
     86        an OPS stable release which both use code from the same GEN
     87        release.</li>
    9288      </ul>
    9389    </li>
    … …  
    10399  </ul>
    104100
    105   <h2><a name="feedback" id="feedback">Feeding Back Changes</a></h2>
     101  <h2 id="feedback">Feeding Back Changes</h2>
    106102
    107103  <p>Although we would encourage all collaborators to make use of the FCM
    … …  
    109105  preferred systems in place. There is no particular problem with this. The
    110106  main requirement is that any proposed changes are provided as a modification
    111   relative to the provided distribution. The changeset could be provided in
    112   the form of a modified project tree or as a patchfile (refer to the man page
    113   for the Unix command <em>patch</em> for details). If the change involves any
    114   renaming or removal of files or directories then special instructions should be
    115   provided plus a script to perform the changes.</p>
     107  relative to the provided distribution. The changeset could be provided in the
     108  form of a modified project tree or as a patchfile (refer to the later section
     109  <a href="#patchfiles">Exchanging Changesets using Patchfiles</a> for further
     110  discussion). If the change involves any renaming or removal of files or
     111  directories then special instructions should be provided plus a script to
     112  perform the changes.</p>
    116113
    117114  <p>At the central repository, the changeset should be applied to a branch
    118115  created from the repository revision which formed the basis of the changeset
    119   (possibly making use of the Subversion utility
    120   <a href="http://svnbook.red-bean.com/en/1.2/svn.advanced.vendorbr.html#svn.advanced.vendorbr.svn_load_dirs">
     116  (possibly making use of the Subversion utility <a href=
     117  "http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.svn_load_dirs">
    121118  svn_load_dirs.pl</a>). Note that extra care is needed with changesets
    122   provided as modified project trees if there are any files in the project which
    123   are excluded from the distribution. Once imported, the changeset should then
    124   undergo any necessary testing or review before being merged into the trunk.</p>
    125 
    126   <h2><a name="usingfcm" id="usingfcm">Collaborating Using FCM for Version
    127   Control</a></h2>
     119  provided as modified project trees if there are any files in the project
     120  which are excluded from the distribution. Once imported, the changeset should
     121  then undergo any necessary testing or review before being merged into the
     122  trunk.</p>
     123
     124  <h2 id="usingfcm">Collaborating Using FCM for Version Control</h2>
    128125
    129126  <p>There are a number of advantages if the FCM system is used for version
    … …  
    135132    release as one big change.</li>
    136133
    137     <li>The process of sending a proposed change to the central repository can be
    138     standardised through the use of an "FCM patch" (explained later).</li>
     134    <li>The process of sending a proposed change to the central repository can
     135    be standardised through the use of an <em>FCM patch</em> (explained
     136    later).</li>
    139137
    140138    <li>The FCM Extract system can be fully utilised.</li>
    … …  
    147145  collaboration.</p>
    148146
    149   <h3><a name="initsvn" id="initsvn">Initialising the Subversion
    150   Repositories</a></h3>
     147  <h3 id="initsvn">Initialising the Subversion Repositories</h3>
    151148
    152149  <p>The collaborator needs to set up a repository and import each of the
    153150  projects. Please see the section <a href=
    154151  "../user_guide/system_admin.html#svn_create">Creating a repository</a> in the
    155   FCM user guide for advice. Collaborators may wish to use separate repositories
    156   and Trac systems for each project or they may prefer to use a single
    157   repository for all projects and use a single Trac system. Either option
    158   should be fine so long as the same set of projects is retained.</p>
     152  FCM user guide for advice. Collaborators may wish to use separate
     153  repositories and Trac systems for each project or they may prefer to use a
     154  single repository for all projects and use a single Trac system. Either
     155  option should be fine so long as the same set of projects is retained.</p>
    159156
    160157  <p>After completing the initial import, the collaborator should have the
    161158  required set of projects available in Subversion where the initial version of
    162   the trunk of each project corresponds with the initial stable release provided
    163   in the distribution.</p>
    164 
    165   <h3><a name="prepchanges" id="prepchanges">Preparing Changes at the
    166   Collaborator's Site</a></h3>
     159  the trunk of each project corresponds with the initial stable release
     160  provided in the distribution.</p>
     161
     162  <h3 id="prepchanges">Preparing Changes at the Collaborator's Site</h3>
    167163
    168164  <p>The recommended way of preparing changes is illustrated in Figure 1a:</p>
    169165
    170   <p class="image"><img src="working-as-collaborator.png" alt=
    171   "Figure 1a: working at the collaborator's site"><br>
    172   Figure 1a: working at the collaborator's site</p>
     166  <p><strong>Figure 1a: working at the collaborator's
     167  site</strong></p>
     168
     169  <p><img src="working-as-collaborator.png" alt=
     170  "Figure 1a: working at the collaborator's site" class="img-polaroid" /></p>
    173171
    174172  <p>The collaborator will create a shared package branch from the latest
    … …  
    177175  create their own development branches. These may be branched from the latest
    178176  stable release on the trunk. Alternatively, if the change needs to build on
    179   other changes then a branch can be created from the shared package branch. When
    180   the changes are ready (i.e. tested, documented, reviewed, etc) then they are
    181   merged into the shared package branch. The trunk is not used for the shared
    182   changes as it is reserved for changes received from the central repository.</p>
     177  other changes then a branch can be created from the shared package branch.
     178  When the changes are ready (i.e. tested, documented, reviewed, etc) then they
     179  are merged into the shared package branch. The trunk is not used for the
     180  shared changes as it is reserved for changes received from the central
     181  repository.</p>
    183182
    184183  <p>Should it be required, a second shared package branch can be created from
    … …  
    188187  Figure 1b:</p>
    189188
    190   <p class="image"><img src="managing-local-changes.png" alt=
    191   "Figure 1b: managing local changes"><br>
    192   Figure 1b: managing local changes</p>
    193 
    194   <h3><a name="feedbackfcm" id="feedbackfcm">Feeding Back Changes Using
    195   FCM</a></h3>
     189  <p><strong>Figure 1b: managing local changes</strong></p>
     190
     191  <p ><img src="managing-local-changes.png" alt=
     192  "Figure 1b: managing local changes" class="img-polaroid" /></p>
     193
     194  <h3 id="feedbackfcm">Feeding Back Changes Using FCM</h3>
    196195
    197196  <p>Eventually, a series of changesets will exist on the first package branch.
    198   These changes will be fed back to the central repository via an "FCM patch".
    199   This contains a series of differences associated with changesets in a given
    200   branch of development, created by the <tt>fcm mkpatch</tt> command. For further
    201   information about the command, please refer to its <a href=
    202   "../user_guide/command_ref.html#fcm_svn_mkpatch">command reference</a> in the
    203   FCM user guide.</p>
     197  These changes will be fed back to the central repository via an <em>FCM
     198  patch</em>. This contains a series of differences associated with changesets
     199  in a given branch of development, created by the <code>fcm mkpatch</code>
     200  command. For further information about the command, please refer to its
     201  <a href="../user_guide/command_ref.html#fcm-mkpatch">command
     202  reference</a> in the FCM user guide.</p>
    204203
    205204  <p>At the central repository, the changeset will be applied to a branch
    … …  
    207206  This is illustrated in Figure 2:</p>
    208207
    209   <p class="image"><img src="feeding-back-patch.png" alt=
    210   "Figure 2: feeding back changes"><br>
    211   Figure 2: feeding back changes</p>
     208  <p><strong>Figure 2: feeding back changes</strong></p>
     209  <p><img src="feeding-back-patch.png" alt=
     210  "Figure 2: feeding back changes" class="img-polaroid" /></p>
    212211
    213212  <p>Patches will usually be exchanged in the form of a tarball. To apply the
    214213  patch it must first be extracted to a directory. In this directory there
    215   should be a shell script called <tt>fcm-import-patch</tt>. A TARGET needs to
    216   be specified when invoking the script. The TARGET must either be a URL or a
    217   working copy of a valid project tree that can accept the import of the
     214  should be a shell script called <code>fcm-import-patch</code>. A TARGET needs
     215  to be specified when invoking the script. The TARGET must either be a URL or
     216  a working copy of a valid project tree that can accept the import of the
    218217  patches. It is essential that this target matches the version of the project
    219218  from which the patch was created (usually this means a particular stable
    220   release). The script contains a series of <tt>cp</tt> and <tt>svn</tt>
    221   commands to import the changesets one by one. Note that the changesets are
    222   committed automatically with no user interaction. It is worth ensuring that
    223   an up to date backup of the repository is available in case of problems.</p>
    224 
    225   <h3><a name="changescentral" id="changescentral">Incorporating Changes into
    226   the Trunk of the Central Repository</a></h3>
     219  release). The script contains a series of <code>cp</code> and
     220  <code>svn</code> commands to import the changesets one by one. Note that the
     221  changesets are committed automatically with no user interaction. It is worth
     222  ensuring that an up to date backup of the repository is available in case of
     223  problems.</p>
     224
     225  <h3 id="changescentral">Incorporating Changes into the Trunk of the Central
     226  Repository</h3>
    227227
    228228  <p>Once the changes have undergone any necessary testing or review they can
    … …  
    238238    still be available to examine on the import branch). This is illustrated in
    239239    Figure 3a:
    240 
    241       <p class="image"><img src="merging-patch-one.png" alt=
    242       "Figure 3a: merging a patch in a single changeset"><br>
    243       Figure 3a: merging a patch in a single changeset</p>
    244240    </li>
    245 
     241  </ol>
     242
     243  <p><strong>Figure 3a: merging a patch in a single changeset</strong></p>
     244
     245  <p><img src="merging-patch-one.png" alt=
     246  "Figure 3a: merging a patch in a single changeset"
     247  class="img-polaroid" /></p>
     248
     249  <ol start="2">
    246250    <li>As multiple changesets: each changeset in the branch will be merged
    247251    into the trunk in order. This can be quite complicated and time consuming,
    … …  
    250254    logical identity, which may be more desirable in the long run, when you
    251255    come to inspect the history. This is illustrated in Figure 3b:
    252 
    253       <p class="image"><img src="merging-patch-multi.png" alt=
    254       "Figure 3b: merging a patch in multiple changesets"><br>
    255       Figure 3b: merging a patch in multiple changesets</p>
    256256    </li>
    257 
     257  </ol>
     258
     259  <p><strong>Figure 3b: merging a patch in multiple changesets</strong></p>
     260
     261  <p><img src="merging-patch-multi.png" alt=
     262  "Figure 3b: merging a patch in multiple changesets"
     263  class="img-polaroid" /></p>
     264
     265  <ol start="3">
    258266    <li>As a mixture of the above: you may want to combine the above two
    259267    approaches when it makes sense to do so. For example, there may be a series
    … …  
    264272  </ol>
    265273
    266   <h3><a name="changescollab" id="changescollab">Incorporating Updates at the
    267   Collaborator's Site</a></h3>
     274  <h3 id="changescollab">Incorporating Updates at the Collaborator's Site</h3>
    268275
    269276  <p>Once a new stable release is available it will be supplied in the form of
    270277  a distribution tarball as described earlier. However, collaborators will also
    271   be supplied with an "FCM patch" (as described earlier) for each project
    272   containing all the changes made since the previous stable release. Note that
    273   this assumes that stable releases are prepared on the trunk and not in
    274   branches.</p>
     278  be supplied with an <em>FCM patch</em> (as described earlier) for each
     279  project containing all the changes made since the previous stable release.
     280  Note that this assumes that stable releases are prepared on the trunk and not
     281  in branches.</p>
    275282
    276283  <p>Each patch should be applied to the trunk of the collaborator's
    277284  repository. This means that the collaborator's trunk will always be mirroring
    278   that of the central repository. This is illustrated in Figure&nbsp;4:</p>
    279 
    280   <p class="image"><img src="mirroring-trunk.png" alt=
    281   "Figure 4: mirroring the trunk at the collaborator's site"><br>
    282   Figure 4: mirroring the trunk at the collaborator's site</p>
     285  that of the central repository. This is illustrated in Figure 4:</p>
     286
     287  <p><strong>Figure 4: mirroring the trunk at the
     288  collaborator's site</strong></p>
     289
     290  <p><img src="mirroring-trunk.png" alt=
     291  "Figure 4: mirroring the trunk at the collaborator's site"
     292  class="img-polaroid"/></p>
    283293
    284294  <p>In order to be certain that the patch has worked correctly, we recommend
    285295  that a check is performed to ensure that the new stable release on the trunk
    286   matches the files provided in the distribution.</p>
    287 
    288   <h3><a name="updatebranches" id="updatebranches">Updating Existing
    289   Branches</a></h3>
     296  matches the files provided in the distribution (preferably using a copy of
     297  the repository for testing purposes before applying the patch to the live
     298  repository).</p>
     299
     300  <h3 id="updatebranches">Updating Existing Branches</h3>
    290301
    291302  <p>Old branches that are still active at the collaborators site should be
    … …  
    295306  deleted once it is no longer required. This is illustrated in Figure 5a:</p>
    296307
    297   <p class="image"><img src="updating-branch.png" alt=
    298   "Figure 5a: updating a branch to the latest stable release"><br>
    299   Figure 5a: updating a branch to the latest stable release</p>
     308  <p><strong>Figure 5a: updating a branch to the latest
     309  stable release</strong></p>
     310
     311  <p><img src="updating-branch.png" alt=
     312  "Figure 5a: updating a branch to the latest stable release"
     313  class="img-polaroid"/></p>
    300314
    301315  <p>Note that the merge will be easiest if the old branch was created from the
    302316  previous stable release. If it was created from the shared package branch
    303   then a custom merge will be required to achieve the desired result. This is
     317  then a custom merge will be required to achieve the desired result (a normal
     318  FCM merge command would choose the wrong base for comparison). This is
    304319  illustrated in Figure 5b:</p>
    305320
    306   <p class="image"><img src="updating-shared-branch.png" alt=
    307   "Figure 5b: updating a branch of the shared package branch"><br>
    308   Figure 5b: updating a branch of the shared package branch</p>
    309 
    310   <h3><a name="other" id="other">Other Scenarios</a></h3>
    311 
    312   <p>The previous sections have only considered how developments on the trunk of
    313   a central repository can be shared with a single collaborator. However, the
    314   same techniques can be applied to more complex situations.</p>
     321  <p><strong>Figure 5b: updating a branch of the shared package
     322  branch</strong></p>
     323
     324  <p><img src="updating-shared-branch.png" alt=
     325  "Figure 5b: updating a branch of the shared package branch"
     326  class="img-polaroid"/></p>
     327
     328  <h3 id="other">Other Scenarios</h3>
     329
     330  <p>The previous sections have only considered how developments on the trunk
     331  of a central repository can be shared with a single collaborator. However,
     332  the same techniques can be applied to more complex situations.</p>
    315333
    316334  <ul>
    317     <li>If there are multiple external collaborators each working with their own
    318     repository then hopefully it is clear that this does not alter things in any
    319     way. Inevitably there will be an increased workload on the maintainers of the
    320     central repository. There will also be an increased need for coordination of
    321     planned code changes. However, the method of code exchange is unaltered.</li>
    322 
    323     <li>Sometimes there may be the need to collaborate on development of a branch
    324     (i.e. to exchange code which is not yet ready to be incorporated onto the
    325     trunk). The collaborator would maintain the trunk of their repository as
    326     before, importing patches to keep their trunk alligned with the stable
    327     releases from the central repository. In addition, they would receive an FCM
    328     patch from the central repository representing the changes on the shared
    329     branch relative to the stable release. The collaborator should create a
    330     branch from the stable release and the patch should then be imported onto
    331     this branch. They should then create a branch from this branch on which to
    332     prepare their changes. When ready the changes would be returned in the form
    333     of an FCM patch, and so on. Hopefully it can be seen that the same process
    334     can be applied to this shared branch as we have previously described for
    335     trunk developments.</li>
     335    <li>If there are multiple external collaborators each working with their
     336    own repository then hopefully it is clear that this does not alter things
     337    in any way. Inevitably there will be an increased workload on the
     338    maintainers of the central repository. There will also be an increased need
     339    for coordination of planned code changes. However, the method of code
     340    exchange is unaltered.</li>
     341
     342    <li>Sometimes there may be the need to collaborate on development of a
     343    branch (i.e. to exchange code which is not yet ready to be incorporated
     344    onto the trunk). The collaborator would maintain the trunk of their
     345    repository as before, importing patches to keep their trunk alligned with
     346    the stable releases from the central repository. In addition, they would
     347    receive an <em>FCM patch</em> from the central repository representing the
     348    changes on the shared branch relative to the stable release. The
     349    collaborator should create a branch from the stable release and the patch
     350    should then be imported onto this branch. They should then create a branch
     351    from this branch on which to prepare their changes. When ready the changes
     352    would be returned in the form of an <em>FCM patch</em>, and so on.
     353    Hopefully it can be seen that the same process can be applied to this
     354    shared branch as we have previously described for trunk developments.</li>
    336355  </ul>
    337356
    338   <h2><a name="further" id="other">Further Considerations</a></h2>
    339 
    340   <p>The previous sections have only considered the version control aspects of a
    341   collaboration. This section lists some other aspects of the collaboration which
    342   will need to be considered.</p>
     357  <h3 id="alternative">An Alternative Branching Strategy</h3>
     358
     359  <p>We have described the branching strategy we believe will work best for
     360  collaborators. However, this is by no means the only branching strategy that
     361  can be used. In particular, some collaborators may prefer to keep the latest
     362  copies of the code they are using on the trunk. This effectively means
     363  getting rid of the shared package branches for shared and local changes and
     364  merging all changes on to the trunk. A separate branch would be used for
     365  keeping a pristine copy of the main site and merging changes from new stable
     366  builds on to the trunk.</p>
     367
     368  <p>This approach is certainly possible and has the advantage that developers
     369  at the collaborator's site may find it easier to work with. However there are
     370  two disadvantages that need to be considered:</p>
     371
     372  <ol>
     373    <li>Merging in changes from a new stable release may be more difficult. If
     374    the new stable release includes changes which were fed back by the
     375    collaborator then these will already be present on the collaborators trunk.
     376    If these changes were modified in any way or if they overlap with other
     377    changes then this will result in a conflict which could be tricky to
     378    resolve.</li>
     379
     380    <li>Any changes which need to be fed back by the collaborator need to be
     381    made relative to a stable release. However, changes will have been prepared
     382    relative to some version of the trunk. This means that a separate branch
     383    will need to be taken (from the branch containing the pristine copy of the
     384    main site) and a custom merge will be required in order to achieve the
     385    desired result.</li>
     386  </ol>
     387
     388  <h3 id="patchfiles">Exchanging Changesets using Patchfiles</h3>
     389
     390  <p>In some cases, an <em>FCM patch</em> may not be the best way of exchanging
     391  changesets. For instance, when distributing code changes which have not yet
     392  been finalised, you probably wouldn't want to send a patch containing all the
     393  individual commits to the branch on which the change is being developed. What
     394  you want is a summary of the changes in a single changeset. In this case you
     395  will often be better to use a patchfile (which can be applied using the Unix
     396  command <code>patch</code>). A patchfile is simply the output from an
     397  <code>fcm diff</code> command. For example:</p>
     398  <pre>
     399fcm diff --branch fcm:myproj-br/dev/frdm/r2134_my_branch &gt; my_patchfile
     400</pre>
     401
     402  <p>The patchfile must be applied to a working copy of the project which
     403  corresponds to the same revision from which the patchfile was generated. The
     404  option <code>-p0</code> must be used with the <code>patch</code> command. For
     405  example:</p>
     406  <pre>
     407patch -p0 &lt; my_patchfile
     408</pre>
     409
     410  <p>Patchfiles have the advantage that they are simple to generate and
     411  exchange and that they can combine the changes from a number of changsets
     412  into one. However, they have a number of limitations such as:</p>
     413
     414  <ul>
     415    <li>Binary files are ignored.</li>
     416
     417    <li>Deleted directories are ignored.</li>
     418
     419    <li>Deleted files are left as empty files.</li>
     420
     421    <li>Copied files appear as new files.</li>
     422
     423    <li>A moved file is treated as a deleted file and a new file.</li>
     424  </ul>
     425
     426  <p>Fortunately these limitations will not be an issue for the majority of
     427  changes and, where they are a problem, there are various options such as
     428  providing additional instructions with the patchfile, using an <em>FCM
     429  patch</em>, or exchanging a modified project tree.</p>
     430
     431  <h2 id="further">Further Considerations</h2>
     432
     433  <p>The previous sections have only considered the version control aspects of
     434  a collaboration. This section lists some other aspects of the collaboration
     435  which will need to be considered.</p>
    343436
    344437  <ul>
    … …  
    346439    system is used. This avoids effort being wasted trying to maintain
    347440    compatibility with an alternate build system. It also ensures that any code
    348     changes prepared by the collaborator are compatible with the coding standards
    349     which the FCM build system requires. Even if there are good reasons for the
    350     collaborator not to use FCM for version control, it is highly recommended
    351     that the FCM build system is used (assuming that is what is used at the
    352     central repository).</li>
     441    changes prepared by the collaborator are compatible with the coding
     442    standards which the FCM build system requires. Even if there are good
     443    reasons for the collaborator not to use FCM for version control, it is
     444    highly recommended that the FCM build system is used (assuming that is what
     445    is used at the central repository).</li>
    353446
    354447    <li>Coding standards should be agreed by all collaborators.</li>
    355448
    356     <li>Working practises should be agreed which should define, amongst other
     449    <li>Working practices should be agreed which should define, amongst other
    357450    things, what level of testing, review and documentation is expected to
    358451    accompany any proposed change.</li>
    359452
    360453    <li>All parties in the collaboration should note the advice given in the
    361     <a href="../user_guide/code_management.html#svn_problems">FCM user guide</a>
    362     to avoid renaming files or directories unless you can ensure that no-one is
    363     working in parallel on the affected areas of the project.</li>
    364 
    365     <li>IPR, copyright and license issues should be agreed by all collaborators.</li>
     454    <a href="../user_guide/code_management.html#svn_problems">FCM user
     455    guide</a> to avoid renaming files or directories unless you can ensure that
     456    no-one is working in parallel on the affected areas of the project.</li>
     457
     458    <li><acronym title="intellectual property rights">IPR</acronym>, copyright
     459    and license issues should be agreed by all collaborators.</li>
    366460  </ul>
    367461
     462  </div>
     463  </div>
     464  </div>
     465
     466  <hr/>
     467  <div class="container-fluid text-center">
     468    <div class="row"><div class="col-md-12">
     469    <address><small>
     470      Copyright &copy; 2006-2021 British Crown (Met Office) &amp; Contributors.
     471      <a href="http://www.metoffice.gov.uk">Met Office</a>.
     472      See <a href="../etc/fcm-terms-of-use.html">Terms of Use</a>.<br />
     473      This document is released under the British <a href=
     474      "http://www.nationalarchives.gov.uk/doc/open-government-licence/" rel=
     475      "license">Open Government Licence</a>.<br />
     476    </small></address>
     477    </div></div>
     478  </div>
     479
     480  <script type="text/javascript" src="../etc/jquery.min.js"></script>
     481  <script type="text/javascript" src="../etc/bootstrap/js/bootstrap.min.js"></script>
     482  <script type="text/javascript" src="../etc/fcm.js"></script>
     483  <script type="text/javascript" src="../etc/fcm-version.js"></script>
    368484</body>
    369485</html>
Note: See TracChangeset for help on using the changeset viewer.