LCG
EDG

Basic CVS commands for TSTG

 Feb, 2003

  • Access to CVS repository
  • Checking out a package from CVS
  • Making Changes in check-out folder.
  • Examine Changes before commit.
  • Getting Latest Update from CVS if necessary
  • Adding and Removing Files
  • Committing Files to CVS
  • Tagging a package.
  • Tagging Conventions
  • History file handling.
  • Adapted from CVS BABAR basics page. Thanks to Terry Hung.


    Access to CVS repository

    http://datagrid.in2p3.fr/cgi-bin/cvsweb.cgi/edg-tests/
     
    Anonymous (read-only) access to DataGrid CVS repository is done via an ssh tunneling. 
    For anonymous (read-only) access no account is required. Define the following variables: 
    $ setenv CVS_RSH /usr/bin/ssh
    $ setenv CVSROOT anoncvs@datagrid.in2p3.fr:/cvs
      
    Configure the ~/.ssh/config file (for ssh1, or ssh2 in protocol 1 emulation):

    Host datagrid.in2p3.fr
    Protocol 1
    Port 2222
    PasswordAuthentication yes
    RSAAuthentication no
    Compression no
    User anoncvs
    More information available  http://datagrid.in2p3.fr/HOWTO/CCIN2P3CVSaccessHOWTO.html
    To get write access, you need to fill in the form and to transmit a copy of your public ssh key.
     

    Checking out package from CVS

       cvs checkout -r tagname edg-tests/
       or 		
       cvs update -r tagname edg-tests/
    

    Making Changes in check-out folder.

      cvs update -dA              [before editing, update to HEAD]
                                  [-d: getting new sub-directories if any]
    
      emacs ..                    [making changes]
    
    It's better updating to the head before making changes.
    Else you may find yourself editing lines that has been revised by someone else.
    If the HEAD version from CVS does not work anymore due to bugs introduced by others, following the following procedure:
       1. Fix <file> and test it in the local test release to prove that the patch works.
       2. 'cvs update -dA <file>' to merge in other's patch if any.
       3. Test again and make sure that the new version still works as much as possible.    
       4. Commit the code. 

    Examine Changes Before Commit [important!!]

    1) Compare files with HEAD:
    
    
       cvs -n update -dA   [list all files that have been modified]
          U {file1}        [there is new version in CVS, no diff needed]
          M {file2}        [there is new version in local folder, need diff]
          C {file3}        [there are new version in CVS and local folder, need diff] 
       cvs diff -Dnow {file}   [examine the diff with HEAD]
    
       One needs to compare files if the label is 'M' or 'C'.
       Use 'cvs diff -Dnow' to compare local version with the HEAD. Look for changes that do not belong to you. 
       If there is none, go to step 4).
       If there are differences that do not belong to you, consider options 2) and 3).
    2) If there is new version in CVS committed by another user. Type:
    
       cvs update -dA          [merge with HEAD version]
    
       then go back to step 1) until only your changes remain in diff. 
    
    3) If your version is actually a copy from a previous version. Type:
    
       mv {file} {file}.old    [save your version]     
       cvs update -dA {file}   [get a fresh copy]
       emacs {file}            [put your changes back] 
    
       then go back to step 1) until only your changes remain in diff.
    
    4) Commit to CVS
    
        cvs commit
    
       Note: do not commit a copy back if you see any changes that do not
       belong to you. When in doubt, always check out a fresh copy and
       start over the editing session.

    Getting Latest Update from CVS if necessary

       cvs -n update -dA        [check how many files has been changed]
         M {file1}              [modified locally]
         C {file2}              [there is new version in CVS, need merging]
       cvs update -dA           [if local version is not head, update it]
    
    
    Use 'cvs -n update -dA' to examine the status of your local folder.
    If there is a file that is labelled 'C' (for Conflict, or Clash), it means this file will need manual merging.
    You can go ahead and do the actual update or make a copy before doing the merging.

    Adding and Removing Files

        cvs add {newfile}           [add new files to local CVS database]
        rm {oldfils}                [remove from disk]
        cvs rm {oldfiles}           [remove from local database CVS/]
    Use 'cvs add filename' to mark a new file for inclusion.
    CVS doesn't put the file in the repository until you do a cvs commit.
    Directories are added with the same command.
    Files within a directory can't be added until the directory is added.

    Committing Files to CVS

        cvs commit                     [now actually commit changes to CVS]
    

    Tagging a package

    After you made changes to a package, updated your local copy and committed your changes to the cvs repository you can tag this package version:
        cvs update -dA              [make sure it is up to date] 
        cvs tag {symbolic tag}      [tag the package]
    
    This will assign the symbolic tag to the repository version that corresponds to your local copy.
    For private use between developers, "private" tags can be made. See Tagging conventions below.

    Tagging conventions

      Main Tags   TSTG-vXX-YY-ZZ(Z)      
    
                  ZZ (2 or 3 digits):    ordinary release
                  YY:                    major release (new functionalities added, new modules)
                  XX:                    brand new code, everything reshuffled, NO backward compatibility
    
    
    Some tag including the initials of the tagger, the date, and an additional optional letter in case of ambiguities.
    This to allow proper identification of the developer, and to solve clashes.
      Private tags XX-ddmmyy(-a)   	for intermediate versions, or to be able to transfer a version to a colleague.
      
      ex. RB-311202-b for Robert Martin,  second private tag of 2002, December 31st
    

    History file handling

       The preparation:
       1) Create an "History" file for main directory and EACH
          sub-directory if any.
       2) Add "$Log: cvs-tstg-basic.html,v $
       2) Add "Revision 1.1.1.1  2003/05/16 13:48:29  lponcet
       2) Add "Website of Grid Deployment
       2) Add "" to each History file.
    
       Upon commit:
       3) Add a carriage return to History file.
       4) Type "cvs ci" or "cvs ci History file1 file2.." to
          expand the key word with actual remarks of commit.
    

    Maintained by TSTG group. Send suggestions and additions to:

    hep-project-grid-tstg@cern.ch