Groundrules for Working With the WHIZARD SVN Repository
=======================================================

  RULE #0:

    Make yourself familiar with the CONCEPTS and PHILOSOPHY of

      SVN  

        http://svnbook.red-bean.com/                   [required reading]

      GNU Autotools

        http://www.gnu.org/software/automake/manual/   [required reading]
        http://www.gnu.org/software/autoconf/manual/
        http://www.gnu.org/software/libtool/manual/


Layout of the Repository
------------------------

  trunk/

    This is the current development version and must ALWAYS compile
    (i.e. "make all" and "make install" must go through).  Under
    extraordinary circumstances, other make targets can fail for a
    short period of time.  Please use branches for medium and large
    scale developments - in particular of the build system.

    (See also "Commiting To the Trunk" below)

  branches/

      Branching is a fundamental part of version control. If you're
      going to allow Subversion to manage your data, this is a
      feature you'll eventually come to depend on.
      [http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge]

    While it is convenient to make SMALL changes that affect only
    one ore two files in the trunk, you are requested to ALWAYS
    perform major surgery in a branch. After you're done, you can
    easily merge your changes to the trunk and subsequently commit a
    werking version.  The SVN Book [http://svnbook.red-bean.com/]
    has all the details.

      branches/jr_reuter/
      branches/kilian/
      branches/ohl/
      branches/speckner/

        Private sandboxes of developers: no rules apply here.

  tags/

    These are snapshots of the code, correspondig to tarballs and to
    checkpoints before and after major surgery.  They should ONLY be
    created with "svn cp" and NEVER be commited to (that's what
    branches are for).


Commiting To the Trunk
----------------------

  RULE #1:

    You may UNDER NO CIRCUMSTANCES commit a version to the trunk in
    which "make all" or "make install" fail with an accepted compiler
    (at the moment: gfortran 4.5 or NAG).

    Repeated violations of this rule will lead to the loss of commit
    priviledges.

  Rationale:

    It is crucial that other developers can "svn update" all the time
    in order to reduce the risk of conflicts without the danger of
    losing the ability to test their contributions.


  RULE #2:

    There can be circumstances in which it is necessary to commit
    versions to the trunk in which one or more of "make check", "make
    installcheck", "make dist" or "make distcheck" fail.  This should
    be avoided, though.

  Rationale:

    Debugging failures of "make distcheck" can take a long time and it
    can be more important to communicate your changes to the other
    developers.


Renaming Files
--------------

  RULE #3:

    If you want to rename a file, NEVER use "cp old-name new-name; svn
    rm old-name; svn add new-name".  Use "svn mv old-name new-name"
    instead.  

  Rationale:

    The first variant might look the same, but destroys
    valuable metainformation, that is required by "svn merge".


See also:

  http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html


Special commits
--------------

  RULE #4:

    Whenever you perform a "milennium" commit (a plain thousand like
    r1000 or r2000), re-grant the write permissions to the WHIZARD
    group on the HepForge svn server by the following commands
    (e.g. for r50000): 

       chmod g+w /hepforge/svn/whizard/db/revs/50
       chmod g+w /hepforge/svn/whizard/db/revprops/50


$Id$
Local Variables:
mode:indented-text
End: