eVLBI CVS maintenance
The LBA eVLBI software is maintained in a CVS archive at the ATNF. Anonymous access is available to CVS repository, however ATNF firewalls essentially close this off from non ATNF access. Shh tunneling allow a workaround for people with an ATNF login.
It is recommended that all observatories have a readonly copy of the eVLBI code in ~vlbi/evlbi (or somewhere similar). This can then be updated whenever needed and there should be no version confusion.
Checking out the eVLBI code
To get a readonly copy of the eVLBI code (from a machine within the ATNF/CSIRO firewalls) you need to:
> cd evlbi
> cd vsib; make
> cd ../util; make
> cd ../RtFC; make
If you are not within the ATNF firewall you will need to setup an ssh tunnel. You need to ssh as any user from the remote machine into an ATNF machine which can "see" atlas. Venice should always work. You can do this like
> cvs -d :pserver:anonymous@localhost:/epp/atapplic/cvsroot checkout evlbi
Where username is your ATNF unix username. The ssh tunnel will exits as long as you stay logged on. An alternative is to ssh into the remote machine from a machine that can "see" atlas (ie any system on the ATNF production network) and and setup an incoming port tunnel, e.g.
> cvs -d :pserver:anonymous@localhost:/epp/atapplic/cvsroot checkout evlbi
This often has the advantage of one less ssh session.
Updating the code
To get a copy of the most recent changes to the CVS repository you simple need to
> cvs update
> cd vsib; make
> cd ../util; make
> cd ../RtFC; make
Don't forget to setup the ssh tunnel first if necessary.
Code development
People who wish to makes changes to eVLBI code need write acess to the CVS repository. At the minimum an ATNF unix login will be required and you need to be in the atnfsrc group. You also need to generate a password hash which is added into the system. See Chris for more details. To checkout a personal copy of the code use:
> cvs -d :pserver:userame@atlas:/epp/atapplic/cvsroot checkout evlbi
where username is your ATNF username (e.g phi196).
Once you have write access to the CVS repository, it would generally be best that any non-trivial changes are made on branches. All changes which are made on the main trunk should be considered stable. The advantage of using branches rather than replying on making changes in your own copy of the code is that you can use CVS to easily distribute the code to multiple observatories for testing (without putting buggy code onto the main trunk).
Creating CVS branches
This is currently not well tested!!! Use with caution
To create a branch:
> cvs tag -b <branch_tag>
This just create the branch on the repository. To change your current working copy to this branch:
To checkout a copy of a branch
To update a working copy with changes from a branch (either another branch or the main tree):
To update a branch to sync with the main tree