The migration of the LHCb repository will happen in steps (by group of pacakges). This page is still valid during the migration process, but it is integrated by SVNUsageGuidelines for what concern the Subversion support.

Using CVS in LHCb

For instructions about the usage of the Subversion repository, look at SVNUsageGuidelines.

Accessing CVS

Web access

• The LHCb repository is world readable via the web, at http://isscvs.cern.ch/cgi-bin/cvsweb.cgi/?cvsroot=lhcb
• Gaudi has migrated to SVN. World read web access to the Gaudi repository is at https://svnweb.cern.ch/world/wsvn/gaudi

Installing the CVS client

• The cvs client is pre-installed on most Linux systems. The distribution for Linux can be obtained from ximbiot.com. If you prefer a GUI lincvs (or crossvc as it is called on newer systems, such as SLC5) is good and available on most systems.
• On Windows we recommend the WinCVS client

Setting up read access

how?

• Linux:

• Windows:

Setting up write access

• Ask the LHCb CVS librarian: Hubert Degaudenzi, or one of his deputies: Marco Cattaneo, Loic Brarda, Joel Closier
• Note that write access is normally granted for a subset of packages only, usually a "Hat" in the directory structure. Please specify the package group for which you require access

Accessing CVS without Kerberos IV (from January 30th 2009 and on)

here

It is important to note that for the users working on the lxplus cluster the change is almost transparent. The ssh client/server on these machine are using the Kerberos V tokens for the ssh authentication. The only part which is mandatory for them is the conversion of the already checked out sources.

The following instructions are detailing the various settings for CVS on standalone or external boxes. Please read them carefully.

Setting up read access

• Linux and MacOS:

• Windows:

and follow the instructions for Linux/MacOS and Windows to create your private/public key pair. For windows, there is however a little change to be done when creating the isscvs.cern.ch session in Putty. When you create your session call it "isscvs.cern.ch" and the host name is the same "isscvs.cern.ch" (in the Session section) and in the Connection->Data section put your autologin name as the user name you want to use. Putty will then forward automatically your user to the isscvs.cern.ch session and then you can simply do a :

Connecting with a different user name

For Linux/MacOSX, this is a little bit different because on these platform the username is always forwarded to the ssh connection. In order to change the username that ssh is using, you have to modify or create the ssh configuration file ~/.ssh/config. In that file, the entry for isscvs.cern.ch should look like:

Host isscvs.cern.ch    
   User myusername    
   Protocol 2
   ForwardX11 no
   IdentityFile ~/.ssh/id_rsa
Host svn.cern.ch
   User myusername
   Protocol 2
   ForwardX11 no
   IdentityFile ~/.ssh/id_rsa

To be noted that this procedure for the setting of the user name reproduces exactly the same behavior as the one with the former kserver method. It prevents the explicit embedding of the user name in the CVSROOT variable. This variable is reproduced in each and every CVS checked out directory (CVS/Root). There is a problem in the release areas and distribution kits if a given user name is hardcoded there. There should be no explicit user name.

Kerberos again

Modifications in getpack

The former behavior of the getpack script with the "ext" (ssh) connection method was to embed the user name in the connection string (":ext:myusername@isscvs.cern.ch:/local/reps/lhcb"). As we have seen above this not a good idea and now getpack doesn't include by default the username in the connection string (":ext:isscvs.cern.ch:/local/reps/lhcb"). The user name has to be tuned in the ssh configuration (~/.ssh/config or Putty) as described above if needed.

For backward compatibility, getpack will add anyway the user name in the "ext" connection string in one case: if the GETPACK_USER variable is defined. This is not recommended and this variable should be unset.

Converting the already checked out software sources

If you don't convert your source directories, you wont be able to do a "cvs diff" or "cvs update" from January 31st 2009 and on.

Guidelines for CVS actions in LHCb

Creating a new package

Guidelines for CVS commit

• Commit often, but commit only code that compiles and runs (i.e. that does not prevent the configuration of the application).
  • Before changing any released package, you should discuss the changes with the package owner (whose name usually appears in the cmt/requirements and doc/release.notes files). It is usually a good idea to inform the appropriate mailing list of the planned changes.
• If this is the first modification to be committed after a release:
  • Increment the version number in the cmt/requirements file
    • Increment the major version ( v) if the change is backward incompatible (change in interfaces, major change in behaviour)
    • Increment the minor version ( r) for a new feature or a bug fix
• Document each commit in the file doc/release.notes
  • Give a brief but meaningful description of the changes ("minor fixes" is not good enough)
    • But no need to document the fix to the fix that you committed a few hours ago
    • Please keep the lines short, max 80 characters per line, carriage return to a new line if necessary.
  • Add your comment above the release separation line (done for you by the <insert> key in the LHCb emacs customisation)

! 2008-06-18 - Marco Cattaneo
 - This is the comment for the latest commit, do not touch anything below this line.
 
!================== GaudiConf v10r9 2008-06-04 ========================

• Check what you are about to commit against the repository:

• • Remove any C in front of a file: C in front of a file means that several people are working on the same package so be careful: CVS has tried to merge your modifications with the changes already done and it has NOT succeeded. Check the merged files carefully: CVS marks with >>>>>> and <<<<<< the regions that have incompatible modifications. You must fix these (and remove the <<<<<< and >>>>>> before committing). Merged files only appear when you do not use the option (-n), but you then need to be more careful of what you do.
    
  • Remove any ? in source directories: These are files that you added and that are not in the repository. If you wish to save them in CVS, you have to

• • Tell CVS to remove from the repository the files you have deleted if any: files that were marked as lost are files that you removed. If you wish to remove them from CVS, issue the comand

• • Check again the package:

• • • Any C should have been replaced by M
    • Any ? should have been replaced by A
    • Any lost should have been replaced by R
  • Finally, commit the package

• Always tag a package after a CVS commit. See the Guidelines for CVS tags
• The next day, check that your commit has not broken other packages
  • Check the nightly builds the day after your commit
  • Fix any packages that were broken by your commit (or ask the package owner to do it)

Guidelines for CVS tag

presented

• It is recommended to use a tag of the form <username>_<yyyymmdd> where <yyyymmdd> is the date of the commit. To tag the repository as of a certain date (e.g. now) do

section 4.6 of the cvs user guide

• Do not use an official tag of the form vxry
• Add the new tag to the tag collector (how?) to inform the release manager of the new tag if you would like it include in the next official release.

How to alter a tag

CVS documentation

Basic CVS commands

here

CVS manual

ximbiot.com

Instructions for LHCb librarians

-- MarcoCattaneo - 23 Jun 2008