New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
system_admin.html in vendors/fcm/current/doc/user_guide – NEMO

source: vendors/fcm/current/doc/user_guide/system_admin.html @ 1977

Last change on this file since 1977 was 1977, checked in by flavoni, 14 years ago

importing fcm vendor
File size: 26.5 KB
Line 
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>FCM User Guide: System Administration</title>
10  <meta name="author" content="FCM development team" />
11  <meta name="descriptions" content="User Guide - System Administration" />
12  <meta name="keywords" content="FCM, user guide" />
13  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
14  <link rel="stylesheet" type="text/css" href="style.css" />
15<script type="text/javascript" src="fcm.js">
16</script>
17</head>
18
19<body onload=
20"javascript: FCM.load('doc/user_guide/', null, [['.', 'FCM User Guide']]);">
21  <div id="document-info">
22    <address id="fcm-js-trail"></address>
23
24    <address id="fcm-js-maintenance"></address>
25  </div>
26
27  <h1>System Administration</h1>
28
29  <div id="fcm-content"></div>
30
31  <h2 id="introduction">Introduction</h2>
32
33  <p>This chapter provides an administration guide for managers of projects or
34  systems which are using FCM.</p>
35
36  <p>Note that, where this section refers to the <em>FCM team</em> this applies
37  only to Met Office users. External users will either need to refer to the
38  equivalent team within their organisation or will need to perfom these tasks
39  themselves.</p>
40
41  <h2 id="svn">Subversion</h2>
42
43  <h3 id="svn_design">Repository design</h3>
44
45  <p>The FCM system assumes that each project directory has sub-directories
46  called <em>trunk</em>, <em>branches</em> and <em>tags</em> (Subversion
47  recommends it but doesn't insist on it). We recommend that each project
48  within a Subversion repository is in a sub-directory of the repository
49  root.</p>
50  <pre>
51&lt;root&gt;
52    |
53    |-- &lt;project 1&gt;
54    |       |
55    |       |-- trunk
56    |       |-- branches
57    |       |-- tags
58    |
59    |-- &lt;project 2&gt;
60    |       |
61    |       |-- trunk
62    |       |-- branches
63    |       |-- tags
64    |
65    |-- ...
66</pre>
67
68  <p>In theory you could also have the project as the root directory or several
69  levels below the root directory. However, this is not tested and could cause
70  problems with some <code>fcm</code> commands so is best avoided.</p>
71
72  <p>You will need to decide whether to use a single project tree for your
73  system or whether to use multiple projects.</p>
74
75  <p>Advantages of a single project tree:</p>
76
77  <ul>
78    <li>Changes to any part of the system can always be committed as a single
79    logical changeset. If you split your system into multiple projects then you
80    may have occasions when a logical change involves more than one project and
81    hence requires multiple commits (and branches).</li>
82  </ul>
83
84  <p>Disadvantages of a single project tree:</p>
85
86  <ul>
87    <li>If you have a large system then your working copies may become very
88    large and unwieldy. Basic commands such as <code>checkout</code> and
89    <code>status</code> can become frustratingly slow if your working copy is
90    too large.</li>
91
92    <li>Depending on how you work, you may end up doing lots more merges of
93    files that are unrelated to your work.</li>
94  </ul>
95
96  <p>One common approach is to split the admin type files (things that only the
97  system manager should need to touch) into a separate project from the core
98  system files (which all the developers need access to). If you include any
99  large data files under version control you may also want to use a separate
100  project for them to avoid making your working copies very large when editing
101  code.</p>
102
103  <p>Note that there is often no obvious right or wrong answer so you just have
104  to make a decision and see how it works out. You can always re-arrange your
105  repository in the future (although be aware that this will break any changes
106  being prepared on branches at the time).</p>
107
108  <p>You also need to decide whether your system requires its own repository
109  (or multiple repositories) or whether it can share with another system.</p>
110
111  <ul>
112    <li>The main disadvantage of having separate repositories for each system
113    is the maintenance overhead (although this is almost all automated by the
114    FCM team so is not a big deal).</li>
115
116    <li>We normally configure a single Trac system per repository. If the
117    repository contains multiple systems then it makes it difficult to use the
118    Trac milestones to handle system releases. However, Trac now supports
119    restricting itself to a sub-directory within a repository so, again, this
120    is not a big deal.</li>
121
122    <li>If you share a repository with other systems then your revision numbers
123    can increase even when there are no changes to your system. This doesn't
124    matter but some people don't like it.</li>
125  </ul>
126
127  <p>For simplicity, in most cases you will probably want your own repository
128  for your system.</p>
129
130  <p>You will not normally want to have multiple repositories for a system. One
131  exception may be if you are storing large data files where you might not want
132  to keep all the old versions for ever. Removing old versions can't be done
133  without changing all the revision numbers which would mess up all your code
134  history and Trac tickets. Storing the large data files in a separate
135  repository reduces the impact if you do decide to remove old versions in the
136  future. One disadvantage of this approach is that, for the moment at least,
137  Trac only handles one repository so you will need a separate Trac system for
138  the data files.</p>
139
140  <p>For further details please see the section <a href=
141  "http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout">
142  Planning Your Repository Organization</a> from the Subversion book.</p>
143
144  <h3 id="svn_create">Creating a repository</h3>
145
146  <p>Normally the FCM team will help you to set up your initial repository.
147  However, it is quite simple if you need to do it yourself. First you need to
148  issue the command <code>svnadmin create /path/to/repos</code>. This creates
149  an empty repository which is now ready to accept an initial import. To do so,
150  you should create a directory tree in a suitable location, and issue the
151  <code>svn import</code> command. At the top level of your directory tree
152  should be the project directories. Each project should then contain three
153  directories <samp>trunk</samp>, <samp>branches</samp> and <samp>tags</samp>.
154  The directories <samp>branches</samp> and <samp>tags</samp> should be empty.
155  The directory <samp>trunk</samp> should contain your source files in a
156  directory structure you have chosen. For example, if your directory tree is
157  located at <samp>$HOME/foo</samp>, you will do the following to import it to
158  a new repository:</p>
159  <pre>
160(SHELL PROMPT)$ svnadmin create FOO_svn
161(SHELL PROMPT)$ svn import $HOME/foo file://$PWD/FOO_svn -m 'Initial import'
162Adding         FOO
163Adding         FOO/trunk
164Adding         FOO/trunk/doc
165Adding         FOO/trunk/doc/hello.html
166Adding         FOO/trunk/doc/world.html
167Adding         FOO/trunk/src
168Adding         FOO/trunk/src/bar
169Adding         FOO/trunk/src/bar/egg.f90
170Adding         FOO/trunk/src/bar/ham.f90
171Adding         FOO/branches
172Adding         FOO/tags
173
174Committed revision 1.
175</pre>
176
177  <p>Note that the <code>svnadmin</code> command takes a <var>PATH</var> as an
178  argument, as opposed to a URL for the <code>svn</code> command.</p>
179
180  <p>For further details please see the section <a href=
181  "http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout">
182  Planning Your Repository Organization</a> from the Subversion book.</p>
183
184  <h3 id="svn_access">Access control</h3>
185
186  <p>You will not normally want to allow anonymous write access to your
187  repository since this means that changes do not get identified with a userid.
188  Therefore system managers need to provide the FCM team with a list of users
189  who should have write access to their repositories. You may also want to
190  arrange passwords for these users although this is only necessary if you need
191  to prevent malicious access. Further restrictions such as preventing
192  anonymous read access or restricting write access to the trunk to a limited
193  set of users can be arranged if necessary.</p>
194
195  <h3 id="svn_hosting">Repository hosting</h3>
196
197  <p>The FCM team will organise the hosting of your repository. A number of
198  facilities will be set up for you as standard.</p>
199
200  <ul>
201    <li>Your repository will be set up on a central FCM server and access will
202    be provided via <code>svnserve</code> (which we use in preference to
203    <cite>Apache</cite> for performance reasons). The FCM team will advise you
204    of the URL.</li>
205
206    <li>Each night a full backup of your repository will be taken. An integrity
207    check will also be performed using the <code>svnadmin verify</code>
208    command.</li>
209
210    <li>Standard hook scripts will be set up to handle the following
211    post-commit tasks:
212
213      <ul>
214        <li>Each time a changeset is successfully committed an incremental dump
215        of the new revision is taken. This would allow the repository to be
216        recovered should the live repository become corrupted for whatever
217        reason.</li>
218
219        <li>A file is updated which records the latest revision of your
220        repository. This can be used by system managers to regularly check for
221        new commits in a cron job and perform any required actions (updating
222        files on a remote platform for instance). The FCM team can advise you
223        of the location of this file and show you some example scripts which
224        make use of it.</li>
225      </ul>
226    </li>
227
228    <li>Standard hook scripts will be set up to handle the following tasks for
229    changes in revision properties (pre-revprop-change/post-revprop-change):
230
231      <ul>
232        <li>If a user attempts to modify the log message of a changeset and
233        he/she is not the original author of the changeset, the
234        pre-revprop-change hook script will e-mail the original author. You can
235        also set up a watch facility to monitor changes of log messages that
236        affect particular paths in the repository. (See the <a href=
237        "#svn_watch">next sub-section</a> for details.)</li>
238
239        <li>The post-revprop-change hook script updates the Trac SQLite
240        database following a successful change in the log message.</li>
241      </ul>
242    </li>
243  </ul>
244
245  <p>Additional hook scripts can be put in place if you have a requirement. The
246  use of hook scripts is discussed in the section <a href=
247  "http://svnbook.red-bean.com/en/1.4/svn.reposadmin.create.html#svn.reposadmin.create.hooks">
248  Repository Creation and Configuration</a> from the Subversion book.</p>
249
250  <p>Note that if you want to use a Subversion repository for your own
251  individual use there is no need to get the FCM team to host it. You can
252  simply create your repository and then use a <code>file://</code> URL to
253  access it.</p>
254
255  <h3 id="svn_watch">Watching changes in log messages</h3>
256
257  <p>You can set up a watch facility to monitor changes in revision log
258  messages in your repository. An obvious use of this facility is for system
259  managers to monitor changes of log messages affecting the trunks of their
260  projects. To set up the facility, you will need to add a
261  <samp>watch.cfg</samp> file to the root of your repository. (To avoid
262  checking out the whole repository, including every branch, make sure that you
263  checkout the root of your repository non-recursively, i.e. <code>fcm checkout
264  -N URL</code>.) The <samp>watch.cfg</samp> file is an INI-type file, with the
265  basic format:</p>
266  <pre>
267[repos_base]
268
269path/in/repos = list,of,watchers
270</pre>
271
272  <p>For example, if your repository is <samp>svn://fcm1/FCM_svn/</samp>, and
273  you want set up particular users to monitor changes of the log messages
274  affecting several areas within the repository, you may have something like
275  this:</p>
276  <pre>
277[FCM_svn]
278
279FCM/trunk/src            = fred,bob
280FCM/trunk/doc            = fred,bob,alice
281FCM/branches/dev/*/*/src = fred
282</pre>
283
284  <p>Later on, if <samp>dave</samp> attempts to modify the log message of a
285  changeset that affects the path <samp>FCM/trunk/src</samp>, <samp>fred</samp>
286  and <samp>bob</samp> will both be notified by e-mail.</p>
287
288  <h2 id="trac">Trac</h2>
289
290  <h3 id="trac_config">Trac configuration</h3>
291
292  <p>Normally the FCM team will set up your Trac system for you (using a script
293  which helps automate the configuration). This section describes some things
294  you may wish to be configured. This can be done when the Trac system is set
295  up or later if you are unsure what you will require at first.</p>
296
297  <h4 id="trac_access">Access control</h4>
298
299  <p>You will not normally want to allow anonymous users to make changes to
300  your Trac system since this means that changes may not get identified with a
301  userid. The FCM team will normally set up your Trac system such that any
302  authenticated users can make changes. Further restrictions such as
303  restricting write access to named accounts or preventing anonymous read
304  access can be arranged if necessary.</p>
305
306  <p>The system manager will normally be given <var>TRAC_ADMIN</var>
307  privileges. This allows them to do additional things which normal users
308  cannot do such as:</p>
309
310  <ul>
311    <li>Delete wiki pages (the latest version or the entire page).</li>
312
313    <li>Add or modify milestones, components and versions.</li>
314
315    <li>Modify ticket descriptions and delete ticket attachments.</li>
316
317    <li>Make wiki pages read-only.</li>
318
319    <li>Alter the permissions.</li>
320  </ul>
321
322  <p>For further details please see the section <a href=
323  "http://trac.edgewall.org/wiki/TracPermissions">Trac Permissions</a> from the
324  Trac documentation.</p>
325
326  <h4 id="trac_email">Email notification</h4>
327
328  <p>By default, each Trac system is configured such that the owner and
329  reporter and anyone on the <var>CC</var> list are notified whenever a change
330  is made to a ticket. If system mangers wish to be notified of all ticket
331  changes then this can also be configured. Alternatively, email notifications
332  can be disabled if they are not wanted.</p>
333
334  <h4 id="trac_milestones">Milestones</h4>
335
336  <p>Milestones are useful for identifying when tickets need to be resolved.
337  Typically, milestones may be particular system releases or time periods. The
338  FCM team can configure milestones for you when they set up your Trac system.
339  However, this is not strictly necessary since milestones can be set up via
340  the web interface using the admin account (go to the <q title=
341  "http://trac.edgewall.org/wiki/TracRoadmap">Roadmap</q> page).</p>
342
343  <h4 id="trac_misc">Other configurable items</h4>
344
345  <p>There are lots of other things that can be configured in your Trac system
346  such as:</p>
347
348  <ul>
349    <li>Custom fields</li>
350
351    <li>System icon</li>
352
353    <li>Stylesheets</li>
354  </ul>
355
356  <p>For further details please see the sections <a href=
357  "http://trac.edgewall.org/wiki/TracIni">The Trac Configuration File</a> and
358  <a href="http://trac.edgewall.org/wiki/TracTickets">The Trac Ticket
359  System</a> from the Trac documentation.</p>
360
361  <h3 id="trac_hosting">Trac hosting</h3>
362
363  <p>The FCM team will organise the hosting of your Trac system. It will be set
364  up on the same server that hosts your Subversion repository and access will
365  be provided via a web server. The FCM team will advise you of the URL. Each
366  night a backup of your Trac system will be taken in case the live system
367  should become corrupted for whatever reason.</p>
368
369  <h2 id="fcm-keywords">FCM keywords</h2>
370
371  <p>When you set up a repository for a new project, you will normally want the
372  FCM team to set up a URL keyword for it in the FCM central configuration
373  file. The name of the project should be a short string containing only word
374  characters.</p>
375
376  <p>Individual projects can store revision keywords using the Subversion
377  property <code>fcm:revision</code> at registered URLs. Using the UM as an
378  example: if <samp>UM</samp> is a registered URL keyword, you can add the
379  <code>fcm:revision</code> property at the head of the UM project by doing a
380  non-recursive checkout. E.g.:</p>
381  <pre>
382(prompt)$ fcm co -q -N fcm:um um
383(prompt)$ fcm pe fcm:revision um
384</pre>
385
386  <p>In the editor, add the following and <code>fcm commit</code>:</p>
387  <pre>
388VN6.3 = 402
389VN6.4 = 1396
390VN6.5 = 2599
391VN6.6 = 4913
392VN7.0 = 6163
393</pre>
394
395  <p>In a subsequent invocation of <code>fcm</code>, if a revision keyword is
396  specified for a URL in the UM namespace, the command will attempt to load it
397  from the <code>fcm:revision</code> property at the head of the UM project.
398  Revision keywords can also be defined in the FCM central configuration file
399  if you prefer.</p>
400
401  <p>If the project has an associated Trac browser, you can also declare
402  browser URL mapping in the central configuration file. This allows FCM to
403  associate the Subversion URL with a Trac browser URL. There is an automatic
404  default for mapping URLs hosted by the FCM team at the Met Office. External
405  users of FCM may want to adjust this default for their site.</p>
406
407  <p>To change the default browser URL mapping, you need to make 3
408  <code>SET::URL_BROWSER_MAPPING_DEFAULT::&lt;key&gt;</code> declarations in
409  your <samp>$FCM/etc/fcm.cfg</samp> file. There are 3 keys to this
410  declaration: <var>LOCATION_COMPONENT_PATTERN</var>,
411  <var>BROWSER_URL_TEMPLATE</var> and <var>BROWSER_REV_TEMPLATE</var>. The
412  <var>LOCATION_COMPONENT_PATTERN</var> is a Perl regular expression, which is
413  used to separate the scheme-specific part of a version control system URL
414  into a number of components by capturing its substrings. These components are
415  then used to fill in the numbered fields in the
416  <var>BROWSER_URL_TEMPLATE</var>. The template should have one more field than
417  the number of components captured by <var>LOCATION_COMPONENT_PATTERN</var>.
418  The last field is used to place the revision, which is generated via the
419  <var>BROWSER_REV_TEMPLATE</var>. This template should have a single numbered
420  field for filling in the revision number. This is best demonstrated by an
421  example. Consider the declarations:</p>
422  <pre>
423%pattern       ^//([^/]+)/(.*)$
424%url_template  http://{1}/intertrac/source:{2}{3}
425%rev_template  @{1}
426set::url_browser_mapping_default::location_component_pattern  %pattern
427set::url_browser_mapping_default::browser_url_template        %url_template
428set::url_browser_mapping_default::browser_rev_template        %rev_template
429</pre>
430
431  <p>If we have a Subversion URL <samp>svn://repos/path/to/a/file</samp>, the
432  <var>LOCATION_COMPONENT_PATTERN</var> will capture the components
433  [<samp>repos</samp>, <samp>path/to/a/file</samp>]. When this is applied to
434  the <code>BROWSER_URL_TEMPLATE</code>, <var>{1}</var> will be translated to
435  <samp>repos</samp> and <var>{2}</var> will be translated to
436  <samp>path/to/a/file</samp>. A revision is not given in this case, and so
437  <var>{3}</var> is inserted with an empty string. The result is
438  <samp>http://repos/intertrac/path/to/a/file</samp>. If the revision is
439  <samp>1357</samp>, the <var>BROWSER_REV_TEMPLATE</var> will be used to
440  translate it to <samp>@1357</samp>, which is then inserted to <var>{3}</var>
441  of the <var>BROWSER_URL_TEMPLATE</var>. The result is therefore
442  <samp>http://repos/intertrac/path/to/a/file@1357</samp>.</p>
443
444  <p>For more information on how to set up the keywords, please refer to
445  <a href="code_management.html#svn_basic_keywords">Repository &amp; Revision
446  Keywords</a> and the <a href="annex_fcm_cfg.html">Annex: Declarations in FCM
447  central/user configuration file</a>.</p>
448
449  <h2 id="ext-bld-cfg">Extract and build configuration</h2>
450
451  <p>The extract and build systems are very flexibile and can be used in lots
452  of different ways. It is therefore difficult to give specific advice
453  explaining how to configure them. However, based on experience with a number
454  of systems, the following general advice can be offered.</p>
455
456  <ul>
457    <li>Standard extract configuration files should be defined and stored
458    within the repository. Users then include these files into their
459    configurations, before applying their local changes.</li>
460
461    <li>The files should be designed to include one another in a hierarchy. For
462    example, you may have one core file which defines all the repository and
463    source locations plus a series of platform/compiler specific files which
464    include the core file. More complex setups are also possible if you need to
465    cater for other options such as different optimisation levels, 32/64 bit,
466    etc.</li>
467
468    <li>When including other configuration files, always make use of the
469    special <var>$HERE</var> variable (rather than, for instance, referring to
470    a fixed repository location). When your configuration file is parsed, this
471    special variable is normally expanded into the container directory of the
472    current configuration file. This means that the include statements should
473    work correctly whether you are referring to configuration files in the
474    repository trunk, in a branch or in a local working copy.</li>
475
476    <li>Make good use of user variables (e.g. <samp>%fred</samp>) to simplify
477    repetitive declarations and make your configuration files easier to
478    maintain.</li>
479
480    <li>Use continuation lines to split long lines and make them easier to read
481    (see the <a href="command_ref.html#fcm_config">FCM Command Reference</a>
482    section for further details about configuration files).</li>
483  </ul>
484
485  <p>Probably the best advice is to look at what has already been set up for
486  other systems. The FCM team can advise on the best systems to examine.</p>
487
488  <p>When you create a stable build you should keep an extract configuration
489  file that can reproduce the build. One easy way to do this is to create your
490  build using the standard configuration files and the latest versions of the
491  code. You can then save the expanded extract configuration file which is
492  created when you run the extract. To help document your stable build you can
493  use the command <code>fcm cmp-ext-cfg</code> to show what has changed.</p>
494
495  <h2 id="alternate_versions">Maintaining alternate versions of namelists and
496  data files</h2>
497
498  <p>Sometimes it is useful to be able to access particular revisions of some
499  directories from a FCM repository without having to go via Subversion.
500  Typical examples are namelist or data files used as inputs to a program. The
501  script <code>fcm_update_version_dir.pl</code> is designed to help with this.
502  It can be used to maintain a set of extracted version directories from a FCM
503  repository. The script has the following options and arguments:</p>
504
505  <dl>
506    <dt><code>-f [--full]</code></dt>
507
508    <dd>Specify the full mode, in which the versioned directories of each
509    specified item will be removed before being re-extracted.</dd>
510
511    <dt><code>-d [--dest] arg</code></dt>
512
513    <dd>Specify a destination <var>arg</var> for the extraction. If not
514    specified, the current working directory will be used as the base
515    path.</dd>
516
517    <dt><code>-u [--url] arg</code></dt>
518
519    <dd>Specify the source repository URL. This option is compulsory.</dd>
520  </dl>
521
522  <p>If an argument is specified, it must be the location of a configuration
523  file. Otherwise, the command reads its configuration from the standard input.
524  The configuration file is a line-based text file. Blank lines and lines
525  beginning with a <samp>#</samp> are ignored.</p>
526
527  <p>Each configuration line must contain the relative path of a sub-directory
528  under the specified source repository URL. If the path ends in <samp>*</samp>
529  then the path is expanded recursively and any sub-directories containing
530  regular files are added to the list of relative paths to extract.</p>
531
532  <p>Optionally, each relative path may be followed by a list of space
533  separated conditions. Each condition is a conditional operator
534  (<code>&gt;</code>, <code>&gt;=</code>, <code>&lt;</code>,
535  <code>&lt;=</code>, <code>==</code> or <code>!=</code>) followed by a
536  revision number or the keyword HEAD.</p>
537
538  <p>The command uses the revision log to determine the revisions at which the
539  relative path has been updated in the source repository URL. If these
540  revisions also satisfy the conditions set by the user, they will be
541  considered in the extraction. In full mode, everything is re-extracted. In
542  incremental mode, the version directories are only updated if they do not
543  already exist.</p>
544
545  <p>Example:</p>
546  <pre>
547(SHELL PROMPT)$ fcm_update_version_dir.pl -u fcm:ver_tr &lt;&lt;EOF
548namelists/VerNL_AreaDefinition   &gt;1000 !=1234
549namelists/VerNL_GRIBToPPCode     &gt;=600 &lt;3000
550namelists/VerNL_StationList     
551elements/*                       &gt;1000
552EOF
553</pre>
554
555  <p>N.B.</p>
556
557  <ol>
558    <li>Each time a sub-directory is revised, the script assigns a sequential
559    <em>v</em> number for the item. Each <em>v</em> number for a sub-directory,
560    therefore, is associated with a revision number. For each extracted
561    revision directory, there is a corresponding <em>v</em> number symbolic
562    link pointing to it.</li>
563
564    <li>The system also creates a symbolic link <samp>latest</samp> to point to
565    the latest extracted revision directory.</li>
566  </ol>
567
568  <h2 id="work-practise">Defining working practises and policies</h2>
569
570  <p>Some options on working practises and policies are defined in the chapter
571  on <a href="working_practices.html">Code Management Working Practices</a>.
572  Individual projects should document the approach they have adopted. In
573  addition, each project may also need to define its own working practices and
574  policies to suit its local need. For example each project may need to
575  specify:</p>
576
577  <ul>
578    <li>Whether changes are allowed directly on the trunk or whether branches
579    have to be used in all cases.</li>
580
581    <li>Whether all users are allowed to make changes to the trunk.</li>
582
583    <li>Whether Trac tickets have to be raised for all changes to the
584    trunk.</li>
585
586    <li>Whether Trac tickets should be raised for all support queries or
587    whether a Trac ticket should only be raised once there is an agreed
588    "issue".</li>
589
590    <li>Whether branches should normally be made from the latest code or from a
591    stable release.</li>
592
593    <li>Whether a user is allowed to resolve conflicts directly when merging a
594    branch into the trunk or whether he/she should merge the trunk into the
595    branch and resolve the conflicts in the branch first.</li>
596
597    <li>Whether all code changes to the trunk need to be reviewed.</li>
598
599    <li>What testing is required before changes can be merged to the
600    trunk.</li>
601
602    <li>Whether history entries are maintained in source files or whether
603    individual source files changes need to be described in the Subversion log
604    message.</li>
605
606    <li>Branch deletion policy.</li>
607
608    <li>Whether any files in the project require locking before being
609    changed.</li>
610  </ul>
611</body>
612</html>
Note: See TracBrowser for help on using the repository browser.