Rivet is hosted by Hepforge, IPPP Durham

Getting Started as a Rivet Developer

We welcome contributors who want to be able to make changes, compile and test them, and submit them for inclusion. If you want to do this you should install Rivet from the Mercurial (hg) repository as described below.

Also you need to make sure you have suitable versions of autotools and libtools installed. If you don't you can download autoconf, automake and libtool from their GNU project pages and then proceed:

    tar xvfz autoconf-2.59.tar.gz
    cd autoconf-2.59
    ./configure [--prefix=[path_to_my_local_directory]]
    make install

    tar xvfz automake-1.9.5.tar.gz}}} 
    cd automake-1.9.5}}} 
    ./configure [--prefix=[path_to_my_local_directory]]
    make
    make install

    tar xvfz libtool-1.5.22.tar.gz
    cd libtool-1.5.22
    ./configure [--prefix=[path_to_my_local_directory]]
    make
    make install

In addition, don't forget to export(setenv) the path for autom4te:
export AUTOM4TE = [path_to_my_local_directory]/bin/autom4te

In order to compile and install Rivet taken from the trunk you will need to install the Boost package. This may already be installed on your system, if not you can find the tar ball here: http://www.boost.org/ Then do:

       tar xvzf boost_X_Y.tar.gz
       cd boost_X_Y
       ./bootstrap.sh
       sudo ./bjam install --prefix=<path>
       cd ..

(for older versions of boost, instead the bootstrap and bjam commands, use

       ./configure --prefix=[path_to_my_local_directory]
       make install

)

This will put the Boost headers in path_to_my_local_directory/include/boost-X_Y/boost

Since Rivet and AGILE expect them to be in path_to_my_local_directory/include/Boost you should configure Rivet/AGILE with the option --with-boost-incpath=path_to_my_local_directory/include/boost-X_Y

Repository access for developers/contributors

Some typical steps in the hg workflow are provided as a reference here. Please refer to http://hginit.com for a complete beginner's tutorial.

  1. Clone the repo -- just once at the beginning
      # anonymous user:
    $ hg clone https://rivet.hepforge.org/hg/rivet
      # or Rivet developer:
    $ hg clone ssh://login.hepforge.org//hepforge/hg/rivet/public/rivet
    $ cd rivet
    $ autoreconf -i
    ($ ./configure [...]; make install; # cf. regular documentation)
    
    Note: The path is automatically encoded in rivet/.hg/hgrc as "default = ssh://login.hepforge.org//hepforge/hg/rivet/public/rivet", so that future pull/push operations do not need an explicit destination.

At present small developments are taking place on the 2.0.x/2.1.x (misnamed) maintenance branch: add -b release-2-0 to the checkout command above, or use hg update release-2-0 to switch a default clone to that branch. Use hg branches to find what branches are available, since maybe we'll forget to update these instructions when the release-2-0 branch is finally closed and new ones are opened for 2.2.x and later.

  1. Implement a new feature locally
    $ hg pull
    $ hg update
    $   # develop first part of change
    $ hg commit -m "first part of my change"
    $   # develop second part of change
    $ hg commit -m "second part of my change"
    
  1. Get updates from central repo
    $ hg pull
    $ hg merge
    $ hg commit -m "merge"
    
  1. Push to central repo
    $ hg push
    
    Note: Push/pull can come from any repo path. You can either explicitly specify the target, or use shortcuts that you can add by hand to .hg/hgrc. This is useful when you're on a branch and want to track trunk as the branch develops. hgrc would then have
    [paths]
    default = ..../branchrepo
    trunk = ..../trunkrepo
    
    Then you can regularly do:
  1. Track trunk in branch repo
    $ hg pull trunk
    $ hg merge
    $ hg ci -m'merge'
    $ hg push  # implies "default"
    
    This keeps 'branch' up-to-date with developments on trunk.
  1. Create new development repo in hepforge
    $ ssh login.hepforge.org
    $ umask 002
    $ cd /hepforge/hg/rivet/
    $ hg clone public/rivet private/foobar
    
    In principle, one can also clone via ssh to a new location in private, but then without the space savings.
  1. Merge branch repo back to trunk
    $ cd privaterepo-workdir
    $ hg pull trunk
    $ hg merge
    $ hg ci -m'merged'
    $ hg out trunk # check what will be pushed, maybe use -r to select
    $ hg push trunk # be SURE of this, it's hard to undo, -r applies here, too
              ^^^^^
    

Once you understand the difference between (3.), (5.) and (7.), you've got it! You can create a couple of local clones on your own machine and experiment with all the different features.

Last modified 3 years ago Last modified on Aug 11, 2014, 3:38:23 PM