[1980] | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" |
---|
| 2 | "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> |
---|
| 3 | |
---|
| 4 | <html xmlns="http://www.w3.org/1999/xhtml"> |
---|
| 5 | <head> |
---|
| 6 | <meta name="generator" content= |
---|
| 7 | "HTML Tidy for Linux/x86 (vers 1st December 2004), see www.w3.org" /> |
---|
| 8 | |
---|
| 9 | <title>External Distribution & Collaboration for FCM Projects</title> |
---|
| 10 | <meta name="author" content="FCM development team" /> |
---|
| 11 | <meta name="descriptions" content= |
---|
| 12 | "External Distribution & Collaboration" /> |
---|
| 13 | <meta name="keywords" content="FCM, distribution, collaboration" /> |
---|
| 14 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
---|
| 15 | <link rel="stylesheet" type="text/css" href="style.css" /> |
---|
| 16 | <script type="text/javascript" src="fcm.js"> |
---|
| 17 | </script> |
---|
| 18 | </head> |
---|
| 19 | |
---|
| 20 | <body onload="javascript: FCM.load('doc/collaboration/', 'collaboration');"> |
---|
| 21 | <div id="ukmo-logo"> |
---|
| 22 | <img src="logo.png" alt="UK Met Office" /> |
---|
| 23 | </div> |
---|
| 24 | |
---|
| 25 | <h1>External Distribution & Collaboration for FCM Projects</h1> |
---|
| 26 | |
---|
| 27 | <address> |
---|
| 28 | Latest content update: 02 Nov 2007. <span id="fcm-js-maintenance"></span> |
---|
| 29 | </address> |
---|
| 30 | |
---|
| 31 | <address> |
---|
| 32 | Questions regarding this document or permissions to quote from it should be |
---|
| 33 | directed to: |
---|
| 34 | </address> |
---|
| 35 | |
---|
| 36 | <address> |
---|
| 37 | <a href="mailto:iprmanager@metoffice.gov.uk">IPR Manager</a><br /> |
---|
| 38 | Met Office<br /> |
---|
| 39 | FitzRoy Road<br /> |
---|
| 40 | Exeter, Devon<br /> |
---|
| 41 | EX1 3PB<br /> |
---|
| 42 | United Kingdom |
---|
| 43 | </address> |
---|
| 44 | |
---|
| 45 | <address> |
---|
| 46 | © Crown Copyright 2006-7 |
---|
| 47 | </address> |
---|
| 48 | |
---|
| 49 | <address id="fcm-js-pdf"></address> |
---|
| 50 | |
---|
| 51 | <hr /> |
---|
| 52 | |
---|
| 53 | <div id="fcm-content"></div> |
---|
| 54 | |
---|
| 55 | <h2 id="introduction">Introduction</h2> |
---|
| 56 | |
---|
| 57 | <p>This document describes how projects configured under FCM can be |
---|
| 58 | distributed externally. Particular attention is given to collaborative |
---|
| 59 | distributions - where the external user regularly returns code for |
---|
| 60 | consolidation into the central repositories which hold the master copies of |
---|
| 61 | the code.</p> |
---|
| 62 | |
---|
| 63 | <p><dfn>Note:</dfn> This document assumes that the repositories are |
---|
| 64 | inaccessible to the external user, due to issues of security and |
---|
| 65 | practicality.</p> |
---|
| 66 | |
---|
| 67 | <h2 id="distribution">Creating a Distribution</h2> |
---|
| 68 | |
---|
| 69 | <p>A system configured under FCM can be distributed by packaging a known |
---|
| 70 | revision (usually corresponding to a stable release) into an archive (e.g. a |
---|
| 71 | tarball) of directories and files. Various issues need to be considered:</p> |
---|
| 72 | |
---|
| 73 | <ul> |
---|
| 74 | <li>A distribution may contain a variety of different files including |
---|
| 75 | source code, scripts, benchmark and validation tests, documentation, |
---|
| 76 | etc.</li> |
---|
| 77 | |
---|
| 78 | <li>A system may consist of several different <em>projects</em> which |
---|
| 79 | should be put into separate directories in the distribution. Please refer |
---|
| 80 | to the section <a href= |
---|
| 81 | "../user_guide/system_admin.html#svn_design">Repository design</a> in the |
---|
| 82 | FCM user guide for an explanation of what is meant by a project in this |
---|
| 83 | context.</li> |
---|
| 84 | |
---|
| 85 | <li>Some files in a project may not be included in the distribution. This |
---|
| 86 | may be because they are of no interest to external users or because of |
---|
| 87 | license restrictions. Such files will need to be filtered out when creating |
---|
| 88 | the distribution.</li> |
---|
| 89 | |
---|
| 90 | <li>The distribution may also contain some files which are not maintained |
---|
| 91 | under FCM version control (test results for instance).</li> |
---|
| 92 | |
---|
| 93 | <li>Some systems share code with other systems. |
---|
| 94 | |
---|
| 95 | <ul> |
---|
| 96 | <li>If a distribution is intended to be used standalone then the |
---|
| 97 | necessary files from these other systems will need to be included. e.g. |
---|
| 98 | The VAR system requires code from the OPS and GEN systems.</li> |
---|
| 99 | |
---|
| 100 | <li>If the distribution is part of a wider collaboration then it is |
---|
| 101 | likely that the files from the other systems will be distributed |
---|
| 102 | separately. It is best if stable releases of the various systems can be |
---|
| 103 | synchronised so that, for example, a VAR stable release uses code from |
---|
| 104 | an OPS stable release which both use code from the same GEN |
---|
| 105 | release.</li> |
---|
| 106 | </ul> |
---|
| 107 | </li> |
---|
| 108 | |
---|
| 109 | <li>Release notes should be prepared to accompany a distribution which |
---|
| 110 | explain, among other things, how the distribution is structured.</li> |
---|
| 111 | |
---|
| 112 | <li>The distribution should contain a file which identifies the repository |
---|
| 113 | revision(s) contained in the distribution.</li> |
---|
| 114 | |
---|
| 115 | <li>System managers will probably wish to maintain a script which automates |
---|
| 116 | the generation of these distributions.</li> |
---|
| 117 | </ul> |
---|
| 118 | |
---|
| 119 | <h2 id="feedback">Feeding Back Changes</h2> |
---|
| 120 | |
---|
| 121 | <p>Although we would encourage all collaborators to make use of the FCM |
---|
| 122 | system for version control, we recognise that they may already have their own |
---|
| 123 | preferred systems in place. There is no particular problem with this. The |
---|
| 124 | main requirement is that any proposed changes are provided as a modification |
---|
| 125 | relative to the provided distribution. The changeset could be provided in the |
---|
| 126 | form of a modified project tree or as a patchfile (refer to the later section |
---|
| 127 | <a href="#patchfiles">Exchanging Changesets using Patchfiles</a> for further |
---|
| 128 | discussion). If the change involves any renaming or removal of files or |
---|
| 129 | directories then special instructions should be provided plus a script to |
---|
| 130 | perform the changes.</p> |
---|
| 131 | |
---|
| 132 | <p>At the central repository, the changeset should be applied to a branch |
---|
| 133 | created from the repository revision which formed the basis of the changeset |
---|
| 134 | (possibly making use of the Subversion utility <a href= |
---|
| 135 | "http://svnbook.red-bean.com/en/1.4/svn.advanced.vendorbr.html#svn.advanced.vendorbr.svn_load_dirs"> |
---|
| 136 | svn_load_dirs.pl</a>). Note that extra care is needed with changesets |
---|
| 137 | provided as modified project trees if there are any files in the project |
---|
| 138 | which are excluded from the distribution. Once imported, the changeset should |
---|
| 139 | then undergo any necessary testing or review before being merged into the |
---|
| 140 | trunk.</p> |
---|
| 141 | |
---|
| 142 | <h2 id="usingfcm">Collaborating Using FCM for Version Control</h2> |
---|
| 143 | |
---|
| 144 | <p>There are a number of advantages if the FCM system is used for version |
---|
| 145 | control by the collaborator. In particular it means that:</p> |
---|
| 146 | |
---|
| 147 | <ul> |
---|
| 148 | <li>Collaborators will be able to see all of the individual changesets |
---|
| 149 | which went in to a new release rather than only being able to view each new |
---|
| 150 | release as one big change.</li> |
---|
| 151 | |
---|
| 152 | <li>The process of sending a proposed change to the central repository can |
---|
| 153 | be standardised through the use of an <em>FCM patch</em> (explained |
---|
| 154 | later).</li> |
---|
| 155 | |
---|
| 156 | <li>The FCM Extract system can be fully utilised.</li> |
---|
| 157 | |
---|
| 158 | <li>Common tools will help to ease communication. We will all use technical |
---|
| 159 | terms to mean the same thing.</li> |
---|
| 160 | </ul> |
---|
| 161 | |
---|
| 162 | <p>This section explains the recommended way of using FCM in a |
---|
| 163 | collaboration.</p> |
---|
| 164 | |
---|
| 165 | <h3 id="initsvn">Initialising the Subversion Repositories</h3> |
---|
| 166 | |
---|
| 167 | <p>The collaborator needs to set up a repository and import each of the |
---|
| 168 | projects. Please see the section <a href= |
---|
| 169 | "../user_guide/system_admin.html#svn_create">Creating a repository</a> in the |
---|
| 170 | FCM user guide for advice. Collaborators may wish to use separate |
---|
| 171 | repositories and Trac systems for each project or they may prefer to use a |
---|
| 172 | single repository for all projects and use a single Trac system. Either |
---|
| 173 | option should be fine so long as the same set of projects is retained.</p> |
---|
| 174 | |
---|
| 175 | <p>After completing the initial import, the collaborator should have the |
---|
| 176 | required set of projects available in Subversion where the initial version of |
---|
| 177 | the trunk of each project corresponds with the initial stable release |
---|
| 178 | provided in the distribution.</p> |
---|
| 179 | |
---|
| 180 | <h3 id="prepchanges">Preparing Changes at the Collaborator's Site</h3> |
---|
| 181 | |
---|
| 182 | <p>The recommended way of preparing changes is illustrated in Figure 1a:</p> |
---|
| 183 | |
---|
| 184 | <p class="image"><img src="working-as-collaborator.png" alt= |
---|
| 185 | "Figure 1a: working at the collaborator's site" /><br /> |
---|
| 186 | Figure 1a: working at the collaborator's site</p> |
---|
| 187 | |
---|
| 188 | <p>The collaborator will create a shared package branch from the latest |
---|
| 189 | stable release on the trunk. This branch will contain all the changes that |
---|
| 190 | will eventually be fed back to the central repository. Developers will also |
---|
| 191 | create their own development branches. These may be branched from the latest |
---|
| 192 | stable release on the trunk. Alternatively, if the change needs to build on |
---|
| 193 | other changes then a branch can be created from the shared package branch. |
---|
| 194 | When the changes are ready (i.e. tested, documented, reviewed, etc) then they |
---|
| 195 | are merged into the shared package branch. The trunk is not used for the |
---|
| 196 | shared changes as it is reserved for changes received from the central |
---|
| 197 | repository.</p> |
---|
| 198 | |
---|
| 199 | <p>Should it be required, a second shared package branch can be created from |
---|
| 200 | the same point to contain any local modifications that will not be fed back |
---|
| 201 | to the central repository. A configuration branch can then be used to combine |
---|
| 202 | the local changes with those destined to be fed back. This is illustrated in |
---|
| 203 | Figure 1b:</p> |
---|
| 204 | |
---|
| 205 | <p class="image"><img src="managing-local-changes.png" alt= |
---|
| 206 | "Figure 1b: managing local changes" /><br /> |
---|
| 207 | Figure 1b: managing local changes</p> |
---|
| 208 | |
---|
| 209 | <h3 id="feedbackfcm">Feeding Back Changes Using FCM</h3> |
---|
| 210 | |
---|
| 211 | <p>Eventually, a series of changesets will exist on the first package branch. |
---|
| 212 | These changes will be fed back to the central repository via an <em>FCM |
---|
| 213 | patch</em>. This contains a series of differences associated with changesets |
---|
| 214 | in a given branch of development, created by the <code>fcm mkpatch</code> |
---|
| 215 | command. For further information about the command, please refer to its |
---|
| 216 | <a href="../user_guide/command_ref.html#fcm_svn_mkpatch">command |
---|
| 217 | reference</a> in the FCM user guide.</p> |
---|
| 218 | |
---|
| 219 | <p>At the central repository, the changeset will be applied to a branch |
---|
| 220 | created from the repository revision which formed the basis of the changeset. |
---|
| 221 | This is illustrated in Figure 2:</p> |
---|
| 222 | |
---|
| 223 | <p class="image"><img src="feeding-back-patch.png" alt= |
---|
| 224 | "Figure 2: feeding back changes" /><br /> |
---|
| 225 | Figure 2: feeding back changes</p> |
---|
| 226 | |
---|
| 227 | <p>Patches will usually be exchanged in the form of a tarball. To apply the |
---|
| 228 | patch it must first be extracted to a directory. In this directory there |
---|
| 229 | should be a shell script called <code>fcm-import-patch</code>. A TARGET needs |
---|
| 230 | to be specified when invoking the script. The TARGET must either be a URL or |
---|
| 231 | a working copy of a valid project tree that can accept the import of the |
---|
| 232 | patches. It is essential that this target matches the version of the project |
---|
| 233 | from which the patch was created (usually this means a particular stable |
---|
| 234 | release). The script contains a series of <code>cp</code> and |
---|
| 235 | <code>svn</code> commands to import the changesets one by one. Note that the |
---|
| 236 | changesets are committed automatically with no user interaction. It is worth |
---|
| 237 | ensuring that an up to date backup of the repository is available in case of |
---|
| 238 | problems.</p> |
---|
| 239 | |
---|
| 240 | <h3 id="changescentral">Incorporating Changes into the Trunk of the Central |
---|
| 241 | Repository</h3> |
---|
| 242 | |
---|
| 243 | <p>Once the changes have undergone any necessary testing or review they can |
---|
| 244 | be merged into the trunk. There are three ways of approaching this:</p> |
---|
| 245 | |
---|
| 246 | <ol> |
---|
| 247 | <li>As one changeset: all changes in the branch will be merged into the |
---|
| 248 | trunk as a single changeset. This approach is the easiest and has the |
---|
| 249 | advantage that any conflicts only need to be resolved once. However, the |
---|
| 250 | drawback of this approach is that the logical changesets as fed back by the |
---|
| 251 | collaborator will be combined into a large single changeset on the trunk, |
---|
| 252 | which may not be the most desirable (although the logical changesets will |
---|
| 253 | still be available to examine on the import branch). This is illustrated in |
---|
| 254 | Figure 3a: |
---|
| 255 | |
---|
| 256 | <p class="image"><img src="merging-patch-one.png" alt= |
---|
| 257 | "Figure 3a: merging a patch in a single changeset" /><br /> |
---|
| 258 | Figure 3a: merging a patch in a single changeset</p> |
---|
| 259 | </li> |
---|
| 260 | |
---|
| 261 | <li>As multiple changesets: each changeset in the branch will be merged |
---|
| 262 | into the trunk in order. This can be quite complicated and time consuming, |
---|
| 263 | especially if you have a large number of changesets and there are a lot of |
---|
| 264 | clashes. The advantage is that each logical changeset will retain its |
---|
| 265 | logical identity, which may be more desirable in the long run, when you |
---|
| 266 | come to inspect the history. This is illustrated in Figure 3b: |
---|
| 267 | |
---|
| 268 | <p class="image"><img src="merging-patch-multi.png" alt= |
---|
| 269 | "Figure 3b: merging a patch in multiple changesets" /><br /> |
---|
| 270 | Figure 3b: merging a patch in multiple changesets</p> |
---|
| 271 | </li> |
---|
| 272 | |
---|
| 273 | <li>As a mixture of the above: you may want to combine the above two |
---|
| 274 | approaches when it makes sense to do so. For example, there may be a series |
---|
| 275 | of small changesets that can be combined logically, or there may be a |
---|
| 276 | changeset that fixes a bug introduced in the previous one. The bottom line |
---|
| 277 | is that the project/system manager should use his/her own judgement in the |
---|
| 278 | matter for what is best for the future of the project.</li> |
---|
| 279 | </ol> |
---|
| 280 | |
---|
| 281 | <h3 id="changescollab">Incorporating Updates at the Collaborator's Site</h3> |
---|
| 282 | |
---|
| 283 | <p>Once a new stable release is available it will be supplied in the form of |
---|
| 284 | a distribution tarball as described earlier. However, collaborators will also |
---|
| 285 | be supplied with an <em>FCM patch</em> (as described earlier) for each |
---|
| 286 | project containing all the changes made since the previous stable release. |
---|
| 287 | Note that this assumes that stable releases are prepared on the trunk and not |
---|
| 288 | in branches.</p> |
---|
| 289 | |
---|
| 290 | <p>Each patch should be applied to the trunk of the collaborator's |
---|
| 291 | repository. This means that the collaborator's trunk will always be mirroring |
---|
| 292 | that of the central repository. This is illustrated in Figure 4:</p> |
---|
| 293 | |
---|
| 294 | <p class="image"><img src="mirroring-trunk.png" alt= |
---|
| 295 | "Figure 4: mirroring the trunk at the collaborator's site" /><br /> |
---|
| 296 | Figure 4: mirroring the trunk at the collaborator's site</p> |
---|
| 297 | |
---|
| 298 | <p>In order to be certain that the patch has worked correctly, we recommend |
---|
| 299 | that a check is performed to ensure that the new stable release on the trunk |
---|
| 300 | matches the files provided in the distribution (preferably using a copy of |
---|
| 301 | the repository for testing purposes before applying the patch to the live |
---|
| 302 | repository).</p> |
---|
| 303 | |
---|
| 304 | <h3 id="updatebranches">Updating Existing Branches</h3> |
---|
| 305 | |
---|
| 306 | <p>Old branches that are still active at the collaborators site should be |
---|
| 307 | updated to the latest stable release when it becomes available. Developers |
---|
| 308 | should create a new branch from the latest stable release and then merge the |
---|
| 309 | changes from the old branch to the new branch. The old branch should be |
---|
| 310 | deleted once it is no longer required. This is illustrated in Figure 5a:</p> |
---|
| 311 | |
---|
| 312 | <p class="image"><img src="updating-branch.png" alt= |
---|
| 313 | "Figure 5a: updating a branch to the latest stable release" /><br /> |
---|
| 314 | Figure 5a: updating a branch to the latest stable release</p> |
---|
| 315 | |
---|
| 316 | <p>Note that the merge will be easiest if the old branch was created from the |
---|
| 317 | previous stable release. If it was created from the shared package branch |
---|
| 318 | then a custom merge will be required to achieve the desired result (a normal |
---|
| 319 | FCM merge command would choose the wrong base for comparison). This is |
---|
| 320 | illustrated in Figure 5b:</p> |
---|
| 321 | |
---|
| 322 | <p class="image"><img src="updating-shared-branch.png" alt= |
---|
| 323 | "Figure 5b: updating a branch of the shared package branch" /><br /> |
---|
| 324 | Figure 5b: updating a branch of the shared package branch</p> |
---|
| 325 | |
---|
| 326 | <h3 id="other">Other Scenarios</h3> |
---|
| 327 | |
---|
| 328 | <p>The previous sections have only considered how developments on the trunk |
---|
| 329 | of a central repository can be shared with a single collaborator. However, |
---|
| 330 | the same techniques can be applied to more complex situations.</p> |
---|
| 331 | |
---|
| 332 | <ul> |
---|
| 333 | <li>If there are multiple external collaborators each working with their |
---|
| 334 | own repository then hopefully it is clear that this does not alter things |
---|
| 335 | in any way. Inevitably there will be an increased workload on the |
---|
| 336 | maintainers of the central repository. There will also be an increased need |
---|
| 337 | for coordination of planned code changes. However, the method of code |
---|
| 338 | exchange is unaltered.</li> |
---|
| 339 | |
---|
| 340 | <li>Sometimes there may be the need to collaborate on development of a |
---|
| 341 | branch (i.e. to exchange code which is not yet ready to be incorporated |
---|
| 342 | onto the trunk). The collaborator would maintain the trunk of their |
---|
| 343 | repository as before, importing patches to keep their trunk alligned with |
---|
| 344 | the stable releases from the central repository. In addition, they would |
---|
| 345 | receive an <em>FCM patch</em> from the central repository representing the |
---|
| 346 | changes on the shared branch relative to the stable release. The |
---|
| 347 | collaborator should create a branch from the stable release and the patch |
---|
| 348 | should then be imported onto this branch. They should then create a branch |
---|
| 349 | from this branch on which to prepare their changes. When ready the changes |
---|
| 350 | would be returned in the form of an <em>FCM patch</em>, and so on. |
---|
| 351 | Hopefully it can be seen that the same process can be applied to this |
---|
| 352 | shared branch as we have previously described for trunk developments.</li> |
---|
| 353 | </ul> |
---|
| 354 | |
---|
| 355 | <h3 id="alternative">An Alternative Branching Strategy</h3> |
---|
| 356 | |
---|
| 357 | <p>We have described the branching strategy we believe will work best for |
---|
| 358 | collaborators. However, this is by no means the only branching strategy that |
---|
| 359 | can be used. In particular, some collaborators may prefer to keep the latest |
---|
| 360 | copies of the code they are using on the trunk. This effectively means |
---|
| 361 | getting rid of the shared package branches for shared and local changes and |
---|
| 362 | merging all changes on to the trunk. A separate branch would be used for |
---|
| 363 | keeping a pristine copy of the main site and merging changes from new stable |
---|
| 364 | builds on to the trunk.</p> |
---|
| 365 | |
---|
| 366 | <p>This approach is certainly possible and has the advantage that developers |
---|
| 367 | at the collaborator's site may find it easier to work with. However there are |
---|
| 368 | two disadvantages that need to be considered:</p> |
---|
| 369 | |
---|
| 370 | <ol> |
---|
| 371 | <li>Merging in changes from a new stable release may be more difficult. If |
---|
| 372 | the new stable release includes changes which were fed back by the |
---|
| 373 | collaborator then these will already be present on the collaborators trunk. |
---|
| 374 | If these changes were modified in any way or if they overlap with other |
---|
| 375 | changes then this will result in a conflict which could be tricky to |
---|
| 376 | resolve.</li> |
---|
| 377 | |
---|
| 378 | <li>Any changes which need to be fed back by the collaborator need to be |
---|
| 379 | made relative to a stable release. However, changes will have been prepared |
---|
| 380 | relative to some version of the trunk. This means that a separate branch |
---|
| 381 | will need to be taken (from the branch containing the pristine copy of the |
---|
| 382 | main site) and a custom merge will be required in order to achieve the |
---|
| 383 | desired result.</li> |
---|
| 384 | </ol> |
---|
| 385 | |
---|
| 386 | <h3 id="patchfiles">Exchanging Changesets using Patchfiles</h3> |
---|
| 387 | |
---|
| 388 | <p>In some cases, an <em>FCM patch</em> may not be the best way of exchanging |
---|
| 389 | changesets. For instance, when distributing code changes which have not yet |
---|
| 390 | been finalised, you probably wouldn't want to send a patch containing all the |
---|
| 391 | individual commits to the branch on which the change is being developed. What |
---|
| 392 | you want is a summary of the changes in a single changeset. In this case you |
---|
| 393 | will often be better to use a patchfile (which can be applied using the Unix |
---|
| 394 | command <code>patch</code>). A patchfile is simply the output from an |
---|
| 395 | <code>fcm diff</code> command. For example:</p> |
---|
| 396 | <pre> |
---|
| 397 | fcm diff --branch fcm:myproj-br/dev/frdm/r2134_my_branch > my_patchfile |
---|
| 398 | </pre> |
---|
| 399 | |
---|
| 400 | <p>The patchfile must be applied to a working copy of the project which |
---|
| 401 | corresponds to the same revision from which the patchfile was generated. The |
---|
| 402 | option <code>-p0</code> must be used with the <code>patch</code> command. For |
---|
| 403 | example:</p> |
---|
| 404 | <pre> |
---|
| 405 | patch -p0 < my_patchfile |
---|
| 406 | </pre> |
---|
| 407 | |
---|
| 408 | <p>Patchfiles have the advantage that they are simple to generate and |
---|
| 409 | exchange and that they can combine the changes from a number of changsets |
---|
| 410 | into one. However, they have a number of limitations such as:</p> |
---|
| 411 | |
---|
| 412 | <ul> |
---|
| 413 | <li>Binary files are ignored.</li> |
---|
| 414 | |
---|
| 415 | <li>Deleted directories are ignored.</li> |
---|
| 416 | |
---|
| 417 | <li>Deleted files are left as empty files.</li> |
---|
| 418 | |
---|
| 419 | <li>Copied files appear as new files.</li> |
---|
| 420 | |
---|
| 421 | <li>A moved file is treated as a deleted file and a new file.</li> |
---|
| 422 | </ul> |
---|
| 423 | |
---|
| 424 | <p>Fortunately these limitations will not be an issue for the majority of |
---|
| 425 | changes and, where they are a problem, there are various options such as |
---|
| 426 | providing additional instructions with the patchfile, using an <em>FCM |
---|
| 427 | patch</em>, or exchanging a modified project tree.</p> |
---|
| 428 | |
---|
| 429 | <h2 id="further">Further Considerations</h2> |
---|
| 430 | |
---|
| 431 | <p>The previous sections have only considered the version control aspects of |
---|
| 432 | a collaboration. This section lists some other aspects of the collaboration |
---|
| 433 | which will need to be considered.</p> |
---|
| 434 | |
---|
| 435 | <ul> |
---|
| 436 | <li>The FCM build system can be used regardless of what version control |
---|
| 437 | system is used. This avoids effort being wasted trying to maintain |
---|
| 438 | compatibility with an alternate build system. It also ensures that any code |
---|
| 439 | changes prepared by the collaborator are compatible with the coding |
---|
| 440 | standards which the FCM build system requires. Even if there are good |
---|
| 441 | reasons for the collaborator not to use FCM for version control, it is |
---|
| 442 | highly recommended that the FCM build system is used (assuming that is what |
---|
| 443 | is used at the central repository).</li> |
---|
| 444 | |
---|
| 445 | <li>Coding standards should be agreed by all collaborators.</li> |
---|
| 446 | |
---|
| 447 | <li>Working practises should be agreed which should define, amongst other |
---|
| 448 | things, what level of testing, review and documentation is expected to |
---|
| 449 | accompany any proposed change.</li> |
---|
| 450 | |
---|
| 451 | <li>All parties in the collaboration should note the advice given in the |
---|
| 452 | <a href="../user_guide/code_management.html#svn_problems">FCM user |
---|
| 453 | guide</a> to avoid renaming files or directories unless you can ensure that |
---|
| 454 | no-one is working in parallel on the affected areas of the project.</li> |
---|
| 455 | |
---|
| 456 | <li><acronym title="intellectual property rights">IPR</acronym>, copyright |
---|
| 457 | and license issues should be agreed by all collaborators.</li> |
---|
| 458 | </ul> |
---|
| 459 | </body> |
---|
| 460 | </html> |
---|