Difference: SVNUsageGuidelines (1 vs. 50)

Revision 502017-01-30 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Changed:
<
<
The LHCb code is kept in a Subversion repository.
>
>
The LHCb code used to kept in a Subversion repository. It has now been migrated to Git

The information in this page is kept for historical reasons. For current usage, refer to the Git4LHCb page

  This set of guidelines about using SVN is specifically for Users and Developers of LHCb code.

Revision 492013-12-16 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 72 to 72
 On the LHCb Windows Terminal Server we install the CollabNet command line client and the TortoiseSVN graphic client (a command line client is mandatory to be able to use getpack).

- Setting up read access

Changed:
<
<
Detailed instructions about how to configure the access to the Subversion repository are provided by IT in the SVN How-To. You can find instructions for Linux and Windows.
>
>
Detailed instructions about how to configure the access to the Subversion repository are provided by IT in the SVN How-To. You can find instructions for Linux and Windows.
  Note: To enable the ssh tunnel for the command line client on Windows (URLs of the form svn+ssh://), you may need to add the line
Line: 118 to 118
  ForwardX11 no IdentityFile ~/.ssh/id_rsa
Changed:
<
<
as explained in the SVN How-To.
>
>
as explained in the SVN How-To.
 

- getpack

After these settings, you are able to get the code (check out) from the repository:

Revision 482013-09-20 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 147 to 147
 
  • Be aware that each project has a release manager who is responsible for the maintainance of the project as a whole. It is best to discuss with the release manager of your project if you are planning major changes, discover a major bug or wish to add a new package. The release manager can also answer many of the questions you may have about svn, branch packages for you, create new packages for you, etc. in case you are not so confident with SVN. The release manager is also the person you will receive an email from if you break some production code.
  • Be aware that each existing packages has a set of authors and developers who maintain the package. It is best to discuss with them if you are planning changes in that package, or discover a bug.
Added:
>
>
If instead you are looking for guidelines on how to do your development efficiently see HLTDevelopersChecklist, and/or discuss with your own release manager in advance of doing anything.

We encourage you to consider TestDrivenDevelopment using the QM-Test framework provided.

 

- Getting write access

To get write access to LHCb Subversion repository, go to the e-group lhcb-svn-writers and register the account you want to use when accessing the Subversion repository. A mail will be sent automatically to the librarians that will add you to the group. Once your subscription is approved it will take few hours before you can actually commit (the privileges are synchronized 3 times per day).

Revision 472013-09-16 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 343 to 343
 and work as if you checked out the trunk. Note that is your branch name does not end with a 'b', you will have to add the option --branch when calling getpack.
Added:
>
>
Once you are done editing, commit as usual:
svn commit -m "committing a modification to the head of the Gen/EvtGen v11r10b branch"

To tag a branch, use the -B option of tag_package (tag_package <package> -B <branchName> <tagName>):

tag_package Gen/EvtGen -B v11r10b v11r10p1
 

- Merging changes across banches

Often, when working with branches, you need to merge in the trunk changes that are on a branch or the other way around.

Revision 462013-06-26 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 144 to 144
  Information:
  • A developer is anyone who writes into the repository, so first you need to get write access (below).
Changed:
<
<
  • Be aware that each project has a release manager who is responsible for the maintainance of the project as a whole. It is best to discuss with the release manager of your project if you are planning major changes, discover a major bug or wish to add a new package. The release manager can also answer many of the questions you may have about svn, branch packages for you, create new packages for you, etc. in case you are not so confident with SVN. The release manager is also the person you will recieve an email from if you break some production code. Instructions for creating a new project are available here
>
>
  • Be aware that each project has a release manager who is responsible for the maintainance of the project as a whole. It is best to discuss with the release manager of your project if you are planning major changes, discover a major bug or wish to add a new package. The release manager can also answer many of the questions you may have about svn, branch packages for you, create new packages for you, etc. in case you are not so confident with SVN. The release manager is also the person you will receive an email from if you break some production code.
 
  • Be aware that each existing packages has a set of authors and developers who maintain the package. It is best to discuss with them if you are planning changes in that package, or discover a bug.

- Getting write access

Line: 152 to 152
  Note that when you register to the e-group lhcb-svn-writers, you will receive the emails sent on the lhcb-core-soft mailing list.
Changed:
<
<

- Creating a new package

If you wish to create a new package and add it to Subversion, follow the guidelines in CreateNewPackageSVN. You can also discuss with your release manager who may do this step for you.
>
>

- Creating a new package or a new project

If you wish to create a new package and add it to Subversion, follow the guidelines in CreateNewPackageSVN. You can also discuss with your release manager who may do this step for you. Creation of new projects should not normally be done by developers; the necessity for a new project should be discussed and agreed at the Physics Applications Coordination (PAC) meeting. Instructions for creating a new project can be found here
 
Changed:
<
<

- Types of modification

>
>

- Modifying a package: Types of modification

  We have three types of modification, which match the three levels of versioning in official tags, vXrYpZ:
  • Major:

Revision 452013-06-20 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 228 to 228
 
      • But no need to document the fix to the fix that you committed a few hours ago, unless it will be confusing for the release manager
      • Please keep the lines short, max 80 characters per line, carriage return to a new line if necessary.

  1. Commit often, but commit only code that compiles and runs
Changed:
<
<
    • Make sure you have compiled the package against the latest software
    • Make sure you have run any relevent qmtests and it's a good idea to write your own new qmtests if a major bug has been fixed or a major change has been made.

>
>
    • Make sure you have compiled the package against the latest software. The code should compile without warnings on at least one platform
    • Make sure you have run any relevant qmtests and it's a good idea to write your own new qmtests if a major bug has been fixed or a major change has been made.

 
  1. Check what you are about to commit against the repository:
    svn status -u
Line: 275 to 275
 
    • We build all our software every night to check for problems
    • The next day, check that your commit has not broken other packages
    • Check the nightly builds the day after your commit
Changed:
<
<
    • Fix any packages that were broken by your commit (or ask the package owner to do it)
>
>
    • Fix any packages that were broken by your commit (or ask the package owner to do it), and fix any compilation warnings (on any platform) or QMTest failures caused by your commit
 
  • It didn't work?
    • Take a look at the FAQ, and email your release manager.

Revision 442013-06-19 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 277 to 277
 
    • 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)
Added:
>
>
  • It didn't work?
    • Take a look at the FAQ, and email your release manager.
 

- Tags and Branches

Revision 432013-05-08 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 184 to 184
  For any bug which affects the production, creating a savannah bug report is considered best-practice.
Added:
>
>

- Working directories

You should only ever develop on top of:

  • The HEAD, "trunk", which is the latest of all changes
  • A recognized branch

Branches can be created for you by your release manager. They are used mostly to patch old software, back-porting changes to previous release stacks.

Working on top of a tag, modifying contents of a tag is forbidden. Ask for a branch or switch to the head.

  • If you are not working with the HEAD revision of a package (i.e. you checked out and modified a tagged version), switch to a directory where you will be able to commit (equivalent of the old cvs update -A preparation before committing):
    • Since TAGGED directories are not supposed to be altered, when committing a change to a package you should, first, switch to the trunk directory. To do so you should
      • Issue the command svn info. That will tell you the actual path of your package:
        svn info
        Path: .
        URL: svn+ssh://svn.cern.ch/reps/lhcb/Rec/tags/Tf/PatAlgorithms/v3r29
        
      • If the URL is of the form above (i.e. it contains the tags subdirectory and a version number), it means you are working against a tagged version. This needs to be altered in order to include trunk in place of tags. You also need to remove the version number at the end of the URL. Do this with the svn switch command:
        svn switch svn+ssh://svn.cern.ch/reps/lhcb/Rec/trunk/Tf/PatAlgorithms
        
    • An alternative is to call getpack again on the same package asking for version trunk from the parent directory:
      getpack Tf/PatAlgorithms trunk
      
 

- Guidelines for SVN commit

Changed:
<
<
  1. Document each commit in the file doc/release.notes
>
>
  1. Discuss with the package owner and/or release manager:
    • 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 they are major or affect a production application, you may also want to come along to PAC.
    • If it is a major bugfix which affected a production application, it is a good idea to make a savannah task, and assign it to yourself, even if it is already fixed.

  2. Document each modification, before committing in the file doc/release.notes
 
    • The release.notes looks something like:
      ! 2009-12-15 - Marco Clemencic
      - This is the comment for the latest commit, do not touch anything below this line.


      !================== GaudiConf v10r9 2008-06-04 ========================
      ! 2008-06-03 - Marco Clemencic
      - Everything up to the official tag line above documents commits which were included in the last release tag,
      - do not touch anything below the tag line, and do not make your own tag lines.

      • Lines with official version numbers are made by the release manager. You shouldn't edit them or make them yourself.
Line: 195 to 227
 
    • Be verbose enough in your release notes so that others can understand what has changed, "minor fixes" is not good enough.
      • But no need to document the fix to the fix that you committed a few hours ago, unless it will be confusing for the release manager
      • Please keep the lines short, max 80 characters per line, carriage return to a new line if necessary.

Deleted:
<
<
  1. Discuss with the package owner and/or release manager:
    • 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 they are major or affect a production application, you may also want to come along to PAC.
    • If it is a major bugfix which affected a production application, it is a good idea to make a savannah task, and assign it to yourself, even if it is already fixed.

 
  1. Commit often, but commit only code that compiles and runs
    • Make sure you have compiled the package against the latest software
    • Make sure you have run any relevent qmtests and it's a good idea to write your own new qmtests if a major bug has been fixed or a major change has been made.

Line: 249 to 277
 
    • 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)
Deleted:
<
<

- Working directories

You should only ever develop on top of:

  • The HEAD, "trunk", which is the latest of all changes
  • A recognized branch

Branches can be created for you by your release manager. They are used mostly to patch old software, back-porting changes to previous release stacks.

Working on top of a tag, modifying contents of a tag is forbidden. Ask for a branch or switch to the head.

  • If you are not working with the HEAD revision of a package (i.e. you checked out and modified a tagged version), switch to a directory where you will be able to commit (equivalent of the old cvs update -A preparation before committing):
    • Since TAGGED directories are not supposed to be altered, when committing a change to a package you should, first, switch to the trunk directory. To do so you should
      • Issue the command svn info. That will tell you the actual path of your package:
        svn info
        Path: .
        URL: svn+ssh://svn.cern.ch/reps/lhcb/Rec/tags/Tf/PatAlgorithms/v3r29
        
      • If the URL is of the form above (i.e. it contains the tags subdirectory and a version number), it means you are working against a tagged version. This needs to be altered in order to include trunk in place of tags. You also need to remove the version number at the end of the URL. Do this with the svn switch command:
        svn switch svn+ssh://svn.cern.ch/reps/lhcb/Rec/trunk/Tf/PatAlgorithms
        
    • An alternative is to call getpack again on the same package asking for version trunk from the parent directory:
      getpack Tf/PatAlgorithms trunk
      
 

- Tags and Branches

Revision 422013-05-06 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 161 to 161
 
  • Major:
    • A change motivated by some major problem or improvement
    • Creating or deprecating a whole package
Changed:
<
<
    • removing something from an interface or a baseclass
>
>
    • removing something from an interface, baseclass, or public inline method
 
    • Adding to or removing something from the DST format
    • Any non-backwards compatible change
    • Fixing a major bug which was a real showstopper

Revision 412013-05-06 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 40 to 40
 
branch_package Create a branch tag of a package. Usually this means copying from one svn location to another branch_package MyHat/MyPackage -T v1r5 v1r5b
svnCheckTags Check that the packages and tags requested in a given requirements file or project.cmt exist. Can also compare the contents with the trunk. svnCheckTags Rec v12r0 --diffs
svnDiffTags Compare the contents of two tagged versions of a package or project and its dependent packages svnDiffTags Rec v11r0 v12r0
Added:
>
>
svnProjectDeps Get a list of all package or project and versions used by a given release. Use "-P" to see only the projects, use "-f Something" to show only matching regex. svnProjectDeps Rec v11r0
 
cmpPackageWithTrunk compare the content of a checked-out (and modified) version of the software with the trunk cmpPackageWithTrunk --all
move_package move a package from one project another move_package MyHat/MyPackage DestinationProject
Line: 135 to 136
  For backward compatibility with the pre-svn version of getpack, if the environment variable GETPACK_USER is defined, getpack will embed the value of that variable in the URL when checking out the code. Since it is not a good idea, check that you do not set that variable and use the above instructions to use the correct username when accessing the repository.
Added:
>
>

- Archaeology, Tracking down changes between versions

See SVNCodeArchaeology.

 

Tutorial and Guidelines for Developers

Information:

Revision 402013-02-05 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 374 to 374
 
move_package MyHat/MyPackage DestinationProject
Added:
>
>
Don't forget to edit also the xxSys/cmt/requirements and xxSys/CMakeLists.txt files of the source and destination projects
 

Subversion documentation

Revision 392012-10-26 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Changed:
<
<
The LHCb code is kept in a Subversion repository (migrated from CVS).
>
>
The LHCb code is kept in a Subversion repository.
  This set of guidelines about using SVN is specifically for Users and Developers of LHCb code.
Line: 12 to 12
 Information:
  • These instructions do not apply to the lhcbdocs repository, only the lhcb code repository.
  • For further instruction also see at Marco's svn tutorial and the FAQ.
Deleted:
<
<
  • For instructions about the usage of the CVS repository, instead, please see CVSUsageGuidelines.

Quick-Reference for cvs users

If you are very used to LHCb CVS guidelines and want a quick-start as to how to migrate to SVN, see CVS2SVNQuickReference

 

Table of Contents

Revision 382012-07-10 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 42 to 42
 
svn info Find information about a local checked out package such as the last person to modify it and the svn path svn info
getpack Checkout from the repository by package name, no need to know the full path to the repository. getpack -rH LHCbSys head
tag_package Create a tag of a package. Usually this means copying from one svn location to another tag_package MyHat/MyPackage me_20110907
Added:
>
>
branch_package Create a branch tag of a package. Usually this means copying from one svn location to another branch_package MyHat/MyPackage -T v1r5 v1r5b
 
svnCheckTags Check that the packages and tags requested in a given requirements file or project.cmt exist. Can also compare the contents with the trunk. svnCheckTags Rec v12r0 --diffs
svnDiffTags Compare the contents of two tagged versions of a package or project and its dependent packages svnDiffTags Rec v11r0 v12r0
cmpPackageWithTrunk compare the content of a checked-out (and modified) version of the software with the trunk cmpPackageWithTrunk --all
Added:
>
>
move_package move a package from one project another move_package MyHat/MyPackage DestinationProject
 

Tutorial and Guidelines for Users, Accessing Subversion

- Web access

Line: 371 to 373
  Note: if you do not specify the revisions to be merged, it will pick up all the changes that have been applied since the branch (or the last merge), so it is better to use this feature when merging from a branch into the trunk.
Added:
>
>

- Moving a package from one project to another

To migrate a package from one project to another, the trunk, the tags and the branches of the package have to be moved and the packages property have to be updated. Everything should be done in a single commit operation to avoid inconsistencies. We have provided an easy to use tool for the task: move_package. The command line looks like this:
move_package MyHat/MyPackage DestinationProject
 

Subversion documentation

- Basic SVN commands

Revision 372012-06-29 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 291 to 291
 
  • Developer and user tags are only useful in certain nontrivial cases, and are of the form <username>_yyyymmdd

The guidelines for tagging in LHCb were presented on 18th June 2008 (33rd LHCb software week)

Changed:
<
<
  • It is recommended to use a tag of the form <username>_<yyyymmdd> where <yyyymmdd> is the date of the commit. If you have to create more than one user tag during the day, you can append a lowercase letter (starting from a) to distinguish them. To tag the repository as of a certain date (e.g. now) do (note: you can use svn info | awk '/^URL/{print $2}' to get the URL of the package you are using)
>
>
  • It is recommended to use a tag of the form <username>_<yyyymmdd> where <yyyymmdd> is the date of the commit. If you have to create more than one user tag during the day, you can append a lowercase letter (starting from a) to distinguish them. To tag the current version in the repository do:
    tag_package Rec/Brunel marcocle_20091215
    
You can also use the low level command (note: you can use svnpath to get the URL of the package) to tag the trunk
 
svn cp svn+ssh://svn.cern.ch/reps/lhcb/Brunel/trunk/Rec/Brunel svn+ssh://svn.cern.ch/reps/lhcb/Brunel/tags/Rec/Brunel/marcocle_20091215
Line: 320 to 324
 
svn cp svn+ssh://svn.cern.ch/reps/lhcb/Gauss/tags/Gen/EvtGen/v11r10 svn+ssh://svn.cern.ch/reps/lhcb/Gauss/branches/Gen/EvtGen/v11r10b
Added:
>
>
or using the shortcut
branch_package Gen/EvtGen -T v11r10 v11r10b
  To work on the branch, just use getpack to check it out (requires LbScripts >= v6r0):

Revision 362012-04-20 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 142 to 142
  Information:
  • A developer is anyone who writes into the repository, so first you need to get write access (below).
Changed:
<
<
  • Be aware that each project has a release manager who is responsible for the maintainance of the project as a whole. It is best to discuss with the release manager of your project if you are planning major changes, discover a major bug or wish to add a new package. The release manager can also answer many of the questions you may have about svn, branch packages for you, create new packages for you, etc. in case you are not so confident with SVN. The release manager is also the person you will recieve an email from if you break some production code.
>
>
  • Be aware that each project has a release manager who is responsible for the maintainance of the project as a whole. It is best to discuss with the release manager of your project if you are planning major changes, discover a major bug or wish to add a new package. The release manager can also answer many of the questions you may have about svn, branch packages for you, create new packages for you, etc. in case you are not so confident with SVN. The release manager is also the person you will recieve an email from if you break some production code. Instructions for creating a new project are available here
 
  • Be aware that each existing packages has a set of authors and developers who maintain the package. It is best to discuss with them if you are planning changes in that package, or discover a bug.

- Getting write access

Revision 352012-04-02 - PatrickSKoppenburg

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 14 to 14
 
Changed:
<
<

*Quick-Reference for cvs users*

>
>

Quick-Reference for cvs users

  If you are very used to LHCb CVS guidelines and want a quick-start as to how to migrate to SVN, see CVS2SVNQuickReference

Revision 342012-02-29 - AnatolySolomin

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 41 to 41
 
Tool Explanation Example
svn info Find information about a local checked out package such as the last person to modify it and the svn path svn info
getpack Checkout from the repository by package name, no need to know the full path to the repository. getpack -rH LHCbSys head
Changed:
<
<
tag_package Create a tag of a package. Usually this means copying from on svn location to another tag_package MyHat/MyPackage me_20110907
>
>
tag_package Create a tag of a package. Usually this means copying from one svn location to another tag_package MyHat/MyPackage me_20110907
 
svnCheckTags Check that the packages and tags requested in a given requirements file or project.cmt exist. Can also compare the contents with the trunk. svnCheckTags Rec v12r0 --diffs
svnDiffTags Compare the contents of two tagged versions of a package or project and its dependent packages svnDiffTags Rec v11r0 v12r0
cmpPackageWithTrunk compare the content of a checked-out (and modified) version of the software with the trunk cmpPackageWithTrunk --all
Line: 85 to 85
 

- Connecting with a different user name

For windows, it is quite simple. You just have to change the autologin name in the "svn.cern.ch" session. You can do it by loading the session in putty and change the username in the Connection->Data section as described in the CERN SVN How-To.
Changed:
<
<
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 svn.cern.ch should look like:
>
>
For Linux/MacOSX, this is a little bit different because on these platforms 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 svn.cern.ch should look like:
 
Host svn.cern.ch svn
   User myusername
Line: 180 to 180
 
    • Doesn't affect the users of this package at all
    • In the case of back-porting onto a branch, the release manager should be consulted.
Changed:
<
<
For any bug which affects the production, creating a savannah bug report is considered best-practise.
>
>
For any bug which affects the production, creating a savannah bug report is considered best-practice.
 

- Guidelines for SVN commit

Line: 240 to 240
 
    • This adds into a database the revision number that was printed by svn after the commit.
    • You do not need to provide a "user tag" as was done for CVS. If you do, for some strange reason, want to provide your own user tag, please follow the guidelines for tags
    • You will select the type of modification from amongst the options, Major, Minor, Patch, as defined above. The release manager will then pick an appropriate tag name when it comes to the release

Changed:
<
<
    • Q: do I really need to use the tag collector. A: It is best-practise, see the explanation here: FAQ
>
>
    • Q: do I really need to use the tag collector. A: It is best-practice, see the explanation here: FAQ
 
  1. Check the nightlies
    • We build all our software every night to check for problems
    • The next day, check that your commit has not broken other packages

Revision 332011-09-08 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 26 to 26
  For a description of how SVN is used in LHCb and overcoming specific problems see: SVNUsageModel.
Added:
>
>

Tools and terms

Term Explanation
the head The most recent software with all committed modifications. Also known as the trunk in svn.
branch A development offshoot which is not compatible with the head and must be handled carefully.
a tag A persistent coherent snapshot of software at a given point in time. A versioned piece of software indicated by the tag name.
an official tag A tag with a name of the form vXrY.
a user tag A tag with the form <user>_yyyymmdd
tagging within the release system, this is the action of creating a tag or set of coherent tags.
tag collecting The collecting of changesets and modifications which are expected to go into a tag. Tag collecting is not tagging.
the tag collector a website interface to a database where revisions are collected before official tags are made

Tool Explanation
<!-- -->
Sorted ascending
Example
svnCheckTags Check that the packages and tags requested in a given requirements file or project.cmt exist. Can also compare the contents with the trunk. svnCheckTags Rec v12r0 --diffs
getpack Checkout from the repository by package name, no need to know the full path to the repository. getpack -rH LHCbSys head
cmpPackageWithTrunk compare the content of a checked-out (and modified) version of the software with the trunk cmpPackageWithTrunk --all
svnDiffTags Compare the contents of two tagged versions of a package or project and its dependent packages svnDiffTags Rec v11r0 v12r0
tag_package Create a tag of a package. Usually this means copying from on svn location to another tag_package MyHat/MyPackage me_20110907
svn info Find information about a local checked out package such as the last person to modify it and the svn path svn info
 

Tutorial and Guidelines for Users, Accessing Subversion

- Web access

  • The LHCb, Gaudi and Dirac repositories are world readable and browsable via the two web interfaces and a statistics page

Revision 322011-08-23 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 126 to 126
 
  • Be aware that each existing packages has a set of authors and developers who maintain the package. It is best to discuss with them if you are planning changes in that package, or discover a bug.

- Getting write access

Changed:
<
<
To get write access to LHCb Subversion repository, go to the e-group lhcb-svn-writers and register the account you want to use when accessing the Subversion repository. A mail will be sent automatically to the librarians that will add you to the group.
>
>
To get write access to LHCb Subversion repository, go to the e-group lhcb-svn-writers and register the account you want to use when accessing the Subversion repository. A mail will be sent automatically to the librarians that will add you to the group. Once your subscription is approved it will take few hours before you can actually commit (the privileges are synchronized 3 times per day).
  Note that when you register to the e-group lhcb-svn-writers, you will receive the emails sent on the lhcb-core-soft mailing list.

Revision 312011-07-11 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 11 to 11
  Information:
  • These instructions do not apply to the lhcbdocs repository, only the lhcb code repository.
Changed:
<
<
>
>
 
  • For instructions about the usage of the CVS repository, instead, please see CVSUsageGuidelines.

*Quick-Reference for cvs users*

Line: 352 to 352
 A summary of SVN commands for CVS users can be found in the Gaudi twiki.

Some simple instructions to migrate an existing CVS checkout to SVN are available at HowToMigrateACvsCheckoutToSvn.

Deleted:
<
<

- FAQ

When I try to commit, I get the message "Cannot modify files in tag directories"

I know that I should have the rights to commit, but when I issue the command svn commit src/MuEffMonitor.cpp -m "bla bla" I get the message:
==>>
Sending        src/MuEffMonitor.cpp
Transmitting file data ....svn: Commit faild (details follow):
svn: Commit blocked by pre-commit hook (exit code 1) with output:
Cannot modify files in tag directories
This is because you are not working with the HEAD of the package. You cannot commit to a tag, you must commit to the trunk or to a branch. See the Guidelines for SVN commit

If necessary the release manager can make a branch for you.

When I try to commit, I get the message "svn: This client is too old to work with working copy 'ThePackage'; please get a newer Subversion client"

This is because the last time you worked with ThePackage (getpack or commit) you must have done so from a machine with a more recent SVN client than the one installed on the current machine. This is a longstanding issue in particular with with slc5, which ships with a very old SVN client. You can 'fix' this by issuing the command change-svn-wc-format
 

- Subversion manual

The complete manual is available from http://svnbook.red-bean.com

Revision 302011-06-17 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 220 to 220
 
    • This adds into a database the revision number that was printed by svn after the commit.
    • You do not need to provide a "user tag" as was done for CVS. If you do, for some strange reason, want to provide your own user tag, please follow the guidelines for tags
    • You will select the type of modification from amongst the options, Major, Minor, Patch, as defined above. The release manager will then pick an appropriate tag name when it comes to the release

Added:
>
>
    • Q: do I really need to use the tag collector. A: It is best-practise, see the explanation here: FAQ
 
  1. Check the nightlies
    • We build all our software every night to check for problems
    • The next day, check that your commit has not broken other packages

Revision 292011-03-01 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 137 to 137
  We have three types of modification, which match the three levels of versioning in official tags, vXrYpZ:
  • Major:
Added:
>
>
    • A change motivated by some major problem or improvement
 
    • Creating or deprecating a whole package
    • removing something from an interface or a baseclass
    • Adding to or removing something from the DST format
Deleted:
<
<
    • Changing the way a user interacts with this package
 
    • Any non-backwards compatible change
    • Fixing a major bug which was a real showstopper
Added:
>
>
    • Changes the way a user interacts with this package
 
    • Major changes should be discussed with the release manager, and in the case of production software they should be presented at PAC.
  • Minor:
Changed:
<
<
    • A significant change, or a cosmetic change
    • Does not affect the users of this package or interface
    • Fixing a small bug which was never exposed in production
>
>
    • A change motivated by improving functionality, adding functionality or improving an existing method
    • A significant change, a cosmetic change, or a small improvement
    • Code re-arrangement, juggling of code between methods, adding new private methods
    • Fixing a bug which was possibly never exposed in production
    • Does not significantly affect the users of this package or interface
    • Needs only cursory discussion with release manager or other developers
 
  • Patch:
Added:
>
>
    • A change motivated by fixing a small issue in the package
 
    • An insignificant change, like changing the release notes or fixing a compiler warning.
    • A hot-fix of a bug which affects the production
Changed:
<
<
    • A back-port of an existing modification to an earlier software release
>
>
    • A back-port of an existing bugfix to an earlier software release
    • Doesn't affect the users of this package at all
 
    • In the case of back-porting onto a branch, the release manager should be consulted.

For any bug which affects the production, creating a savannah bug report is considered best-practise.

Revision 282011-03-01 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Line: 133 to 133
 

- Creating a new package

If you wish to create a new package and add it to Subversion, follow the guidelines in CreateNewPackageSVN. You can also discuss with your release manager who may do this step for you.
Added:
>
>

- Types of modification

We have three types of modification, which match the three levels of versioning in official tags, vXrYpZ:

  • Major:
    • Creating or deprecating a whole package
    • removing something from an interface or a baseclass
    • Adding to or removing something from the DST format
    • Changing the way a user interacts with this package
    • Any non-backwards compatible change
    • Fixing a major bug which was a real showstopper
    • Major changes should be discussed with the release manager, and in the case of production software they should be presented at PAC.
  • Minor:
    • A significant change, or a cosmetic change
    • Does not affect the users of this package or interface
    • Fixing a small bug which was never exposed in production
  • Patch:
    • An insignificant change, like changing the release notes or fixing a compiler warning.
    • A hot-fix of a bug which affects the production
    • A back-port of an existing modification to an earlier software release
    • In the case of back-porting onto a branch, the release manager should be consulted.

For any bug which affects the production, creating a savannah bug report is considered best-practise.

 

- Guidelines for SVN commit

Line: 146 to 169
 
      • Please keep the lines short, max 80 characters per line, carriage return to a new line if necessary.

  1. Discuss with the package owner and/or release manager:
    • 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).
Changed:
<
<
    • It is usually a good idea to inform the appropriate mailing list of the planned changes if they are major or affect a production application.
>
>
    • It is usually a good idea to inform the appropriate mailing list of the planned changes if they are major or affect a production application, you may also want to come along to PAC.
 
    • If it is a major bugfix which affected a production application, it is a good idea to make a savannah task, and assign it to yourself, even if it is already fixed.

  1. Commit often, but commit only code that compiles and runs
    • Make sure you have compiled the package against the latest software
Line: 189 to 212
 
  1. Use the LHCbTagCollector
    • If the package is part of a production project, like Rec, Phys, Analysis etc. then you need to add it to the LHCbTagCollector so that the release manager will know what to do with your changes for the release.
    • This adds into a database the revision number that was printed by svn after the commit.
Changed:
<
<
    • You do not need to provide a "user tag" as was done for CVS. If you do, for some strange reason, want to provide your own user tag, please follow the guidelines for tags

>
>
    • You do not need to provide a "user tag" as was done for CVS. If you do, for some strange reason, want to provide your own user tag, please follow the guidelines for tags
    • You will select the type of modification from amongst the options, Major, Minor, Patch, as defined above. The release manager will then pick an appropriate tag name when it comes to the release

 
  1. Check the nightlies
    • We build all our software every night to check for problems
    • The next day, check that your commit has not broken other packages

Revision 272011-03-01 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"
Changed:
<
<

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial and the FAQ.
>
>

Using Subversion (svn) in LHCb

 
Changed:
<
<
For instructions about the usage of the CVS repository, look at CVSUsageGuidelines.
>
>
The LHCb code is kept in a Subversion repository (migrated from CVS).
 
Changed:
<
<

Quick-Reference for cvs users

>
>
This set of guidelines about using SVN is specifically for Users and Developers of LHCb code.
 
Changed:
<
<
CVS2SVNQuickReference
>
>
Information:
  • These instructions do not apply to the lhcbdocs repository, only the lhcb code repository.
  • For further instruction also see at Marco's svn tutorial and the FAQ.
  • For instructions about the usage of the CVS repository, instead, please see CVSUsageGuidelines.
 
Changed:
<
<

Table of Contents

>
>

*Quick-Reference for cvs users*

If you are very used to LHCb CVS guidelines and want a quick-start as to how to migrate to SVN, see CVS2SVNQuickReference

Table of Contents

 

Line: 17 to 26
  For a description of how SVN is used in LHCb and overcoming specific problems see: SVNUsageModel.
Changed:
<
<

Accessing Subversion

Web access

>
>

Tutorial and Guidelines for Users, Accessing Subversion

- Web access

 
Line: 35 to 44
  The layout of the repository is based on the rules outlined in the Gaudi twiki.
Changed:
<
<

Installing the Subversion client

>
>

- Installing the Subversion client

 The Subversion command line client svn is available in all Linux distributions with names like subversion or subversion-client. It is available by default on lxplus5 nodes, but it might not be installed on other machines, but you can easily find on the web how to install it for your distribution.

For Windows, MacOS (and for Linux distributions that do not have it packaged) you can find the sources and pre-compiled distributions linked from the official Subversion web site.

Line: 44 to 53
  On the LHCb Windows Terminal Server we install the CollabNet command line client and the TortoiseSVN graphic client (a command line client is mandatory to be able to use getpack).
Changed:
<
<

Setting up read access

>
>

- Setting up read access

 Detailed instructions about how to configure the access to the Subversion repository are provided by IT in the SVN How-To. You can find instructions for Linux and Windows.

Note: To enable the ssh tunnel for the command line client on Windows (URLs of the form svn+ssh://), you may need to add the line

Line: 53 to 62
  to the [tunnels] section of the subversion client configuration file (either the user or the global one), see the Subversion book for details.
Changed:
<
<

Getting write access

To get write access to LHCb Subversion repository, go to the e-group lhcb-svn-writers and register the account you want to use when accessing the Subversion repository. A mail will be sent automatically to the librarians that will add you to the group.

Note that when you register to the e-group lhcb-svn-writers, you will receive the emails sent on the lhcb-core-soft mailing list.

Connecting with a different user name

>
>

- Connecting with a different user name

 For windows, it is quite simple. You just have to change the autologin name in the "svn.cern.ch" session. You can do it by loading the session in putty and change the username in the Connection->Data section as described in the CERN SVN How-To.

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 svn.cern.ch should look like:

Line: 78 to 82
  To be noted that this procedure for the setting of the user name prevents the explicit embedding of the user name in the URL of the repository. There is a problem in the release areas and distribution kits if a given user name is hard-coded in the URL. There should be no explicit user name.
Changed:
<
<

Kerberos authentication (Linux/MacOSX)

>
>

- Kerberos authentication (Linux/MacOSX)

 It is possible to use the Kerberos V token to connect to the Subversion server instead of the ssh key, simply modifying the content of the .ssh/config file as
Host svn.cern.ch
Line: 98 to 102
  as explained in the SVN How-To.
Changed:
<
<

getpack

>
>

- getpack

 After these settings, you are able to get the code (check out) from the repository:
svn co svn+ssh://svn.cern.ch/reps/lhcb/AProject/trunk/MyPackage
Line: 114 to 118
  For backward compatibility with the pre-svn version of getpack, if the environment variable GETPACK_USER is defined, getpack will embed the value of that variable in the URL when checking out the code. Since it is not a good idea, check that you do not set that variable and use the above instructions to use the correct username when accessing the repository.
Changed:
<
<

Guidelines for SVN actions in LHCb

Creating a new package

If you wish to create a new package and add it to Subversion, follow the guidelines in CreateNewPackageSVN.
>
>

Tutorial and Guidelines for Developers

Information:

  • A developer is anyone who writes into the repository, so first you need to get write access (below).
  • Be aware that each project has a release manager who is responsible for the maintainance of the project as a whole. It is best to discuss with the release manager of your project if you are planning major changes, discover a major bug or wish to add a new package. The release manager can also answer many of the questions you may have about svn, branch packages for you, create new packages for you, etc. in case you are not so confident with SVN. The release manager is also the person you will recieve an email from if you break some production code.
  • Be aware that each existing packages has a set of authors and developers who maintain the package. It is best to discuss with them if you are planning changes in that package, or discover a bug.

- Getting write access

To get write access to LHCb Subversion repository, go to the e-group lhcb-svn-writers and register the account you want to use when accessing the Subversion repository. A mail will be sent automatically to the librarians that will add you to the group.

Note that when you register to the e-group lhcb-svn-writers, you will receive the emails sent on the lhcb-core-soft mailing list.

- Creating a new package

If you wish to create a new package and add it to Subversion, follow the guidelines in CreateNewPackageSVN. You can also discuss with your release manager who may do this step for you.
 
Changed:
<
<

Guidelines for SVN 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 behavior)
      • 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)
      ! 2009-12-15 - Marco Clemencic
      - This is the comment for the latest commit, do not touch anything below this line.


      !================== GaudiConf v10r9 2008-06-04 ========================
  • If you are not working with the HEAD revision of a package (i.e. you checked out and modified a tagged version), switch to a directory where you will be able to commit (equivalent of the old cvs update -A preparation before committing):
    • Since TAGGED directories are not supposed to be altered, when committing a change to a package you should, first, switch to the trunk directory. To do so you should
      • Issue the command svn info. That will tell you the actual path of your package:
        svn info
        Path: .
        URL: svn+ssh://svn.cern.ch/reps/lhcb/Rec/tags/Tf/PatAlgorithms/v3r29
        
      • If the URL is of the form above (i.e. it contains the tags subdirectory and a version number), it means you are working against a tagged version. This needs to be altered in order to include trunk in place of tags. You also need to remove the version number at the end of the URL. Do this with the svn switch command:
        svn switch svn+ssh://svn.cern.ch/reps/lhcb/Rec/trunk/Tf/PatAlgorithms
        
    • An alternative is to call getpack again on the same package asking for version trunk from the parent directory:
      getpack Tf/PatAlgorithms trunk
      
  • Check what you are about to commit against the repository:
>
>

- Guidelines for SVN commit

  1. Document each commit in the file doc/release.notes
    • The release.notes looks something like:
      ! 2009-12-15 - Marco Clemencic
      - This is the comment for the latest commit, do not touch anything below this line.


      !================== GaudiConf v10r9 2008-06-04 ========================
      ! 2008-06-03 - Marco Clemencic
      - Everything up to the official tag line above documents commits which were included in the last release tag,
      - do not touch anything below the tag line, and do not make your own tag lines.

      • Lines with official version numbers are made by the release manager. You shouldn't edit them or make them yourself.
      • When using the LHCb-flavour of emacs, the release.notes is templated. Just hit Insert to start your release comment
    • Be verbose enough in your release notes so that others can understand what has changed, "minor fixes" is not good enough.
      • But no need to document the fix to the fix that you committed a few hours ago, unless it will be confusing for the release manager
      • Please keep the lines short, max 80 characters per line, carriage return to a new line if necessary.

  2. Discuss with the package owner and/or release manager:
    • 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 they are major or affect a production application.
    • If it is a major bugfix which affected a production application, it is a good idea to make a savannah task, and assign it to yourself, even if it is already fixed.

  3. Commit often, but commit only code that compiles and runs
    • Make sure you have compiled the package against the latest software
    • Make sure you have run any relevent qmtests and it's a good idea to write your own new qmtests if a major bug has been fixed or a major change has been made.

  4. Check what you are about to commit against the repository:
 
svn status -u
Line: 163 to 166
 
    • Tell SVN 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 SVN, issue the comand
      svn rm TheFileToRemove
Changed:
<
<
    • Check again the package:
>
>

    1. Check for conflicts:
 
svn update
      • Any C should have been replaced by M
      • Any ? should have been replaced by A, or just ignored, you may have several ? left
Changed:
<
<
      • Any ! should have been replaced by R
    • Finally, commit the package
>
>
      • Any ! should have been replaced by R 1 Check for, and fix conflicts before committing:
      • If there are any remaining conflicts, discuss with your release manager.

    1. Commit, always with a meaningful comment
 
svn commit
Line: 180 to 184
 
svn commit -m "some brief and meaningful comment"
Changed:
<
<
  • If the package is part of a production project, like Rec, Phys, Analysis etc. then you should add it to the LHCbTagCollector so that the release manager will know what to do with your changes for the release. Use as "tag" the revision number that was printed by svn after the commit. You do not need to provide a "user tag" as was done for CVS. If you do want to provide your own tag, please follow the guidelines for tags
>
>
P.S. "minor changes" is still not good enough, and "some brief and meaningful comment" is also not such a funny joke. The comment can be the same as the release notes, often that helps the release manager

  1. Use the LHCbTagCollector
    • If the package is part of a production project, like Rec, Phys, Analysis etc. then you need to add it to the LHCbTagCollector so that the release manager will know what to do with your changes for the release.
    • This adds into a database the revision number that was printed by svn after the commit.
    • You do not need to provide a "user tag" as was done for CVS. If you do, for some strange reason, want to provide your own user tag, please follow the guidelines for tags

  2. Check the nightlies
    • We build all our software every night to check for problems
 
  • 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)
Added:
>
>

- Working directories

 
Changed:
<
<

Guidelines for tags

>
>
You should only ever develop on top of:
  • The HEAD, "trunk", which is the latest of all changes
  • A recognized branch

Branches can be created for you by your release manager. They are used mostly to patch old software, back-porting changes to previous release stacks.

Working on top of a tag, modifying contents of a tag is forbidden. Ask for a branch or switch to the head.

  • If you are not working with the HEAD revision of a package (i.e. you checked out and modified a tagged version), switch to a directory where you will be able to commit (equivalent of the old cvs update -A preparation before committing):
    • Since TAGGED directories are not supposed to be altered, when committing a change to a package you should, first, switch to the trunk directory. To do so you should
      • Issue the command svn info. That will tell you the actual path of your package:
        svn info
        Path: .
        URL: svn+ssh://svn.cern.ch/reps/lhcb/Rec/tags/Tf/PatAlgorithms/v3r29
        
      • If the URL is of the form above (i.e. it contains the tags subdirectory and a version number), it means you are working against a tagged version. This needs to be altered in order to include trunk in place of tags. You also need to remove the version number at the end of the URL. Do this with the svn switch command:
        svn switch svn+ssh://svn.cern.ch/reps/lhcb/Rec/trunk/Tf/PatAlgorithms
        
    • An alternative is to call getpack again on the same package asking for version trunk from the parent directory:
      getpack Tf/PatAlgorithms trunk
      
 
Changed:
<
<
Users do not need to make tags in SVN, since the revision number provides the same information, but you can, if necessary, or if you are the project manager for example.
>
>

- Tags and Branches

 
Changed:
<
<
Tagging in Subversion, if you are used to another version control system, may appear strange. The concept of tag and branch are not available in Subversion, but they can be easily emulated using a convention, thanks to the ability of Subversion of remembering the history of the whole repository (including directories).
>
>
Tagging in Subversion, if you are used to another version control system, may appear strange. The concept of tag and branch are not natively available in Subversion, but they can be easily emulated using a convention, thanks to the ability of Subversion of remembering the history of the whole repository (including directories).
  The standard convention used in almost all the projects hosted on Subversion (a notable exception being CMT) is based on the presence of three directories called trunk, tags and branches. The trunk contains the main line of development of your code. tags and branches contains copies of the trunk with symbolic names (like v1r2 or 2.3.4). There is no technical difference between tags and branches, but the convention is that you are not supposed to commit changes to a file in the tags directory.

The convention used for the repository layout in LHCb is described in detail in GaudiSVNRepository.

Added:
>
>

- Guidelines for tags

Users and Developers do not need to make tags in SVN, since the revision number provides the same information, but you can, if necessary, or if you are the release manager.

  • Tagging in subversion is a copy from one place to another in the file system
  • Do not use an official tag of the form vxry
  • ... i.e. Only release managers are supposed to make official tags of the form vXrY
  • Developer and user tags are only useful in certain nontrivial cases, and are of the form <username>_yyyymmdd
 The guidelines for tagging in LHCb were presented on 18th June 2008 (33rd LHCb software week)
  • It is recommended to use a tag of the form <username>_<yyyymmdd> where <yyyymmdd> is the date of the commit. If you have to create more than one user tag during the day, you can append a lowercase letter (starting from a) to distinguish them. To tag the repository as of a certain date (e.g. now) do (note: you can use svn info | awk '/^URL/{print $2}' to get the URL of the package you are using)

Line: 207 to 249
 svn cp . svn+ssh://svn.cern.ch/reps/lhcb/Brunel/tags/Rec/Brunel/marcocle_20091215 See GaudiSVNRepository for a description of the tags conventions in the LHCb Subversion repository.
Deleted:
<
<
  • Do not use an official tag of the form vxry
 
Changed:
<
<

How to alter a tag

Modifying the content of a tag is always a bad policy.
>
>

- How to alter a tag

It is not permitted to change the content of an existing tag. Modifying the content of a tag is always a bad policy.
 
Changed:
<
<
If you really have to do it because after a tag you realized you forgot to do a commit and it is a "user tag" then it is better to create a new tag.
>
>
If you have made a "user tag" of the form <username>_<yyyymmdd>= then you can just create a new tag with the new fix.
 
Changed:
<
<
To retag you have to delete the tag you created with something like:
>
>
To remove the knowledge of the previous tag you have to delete the tag you created with something like:
 
svn rm svn+ssh://svn.cern.ch/reps/lhcb/Brunel/tags/Rec/Brunel/marcocle_20091215
Changed:
<
<
then re-create the tag with the instructions in the previous section.
>
>
then it is possible, but not advisable to re-create the tag with the instructions in the previous section.
 
Changed:
<
<

Working with branches

>
>

- Working with branches

It's a good idea to let the release manager know when you want to do some changes on a branch. The release manager can create the branches for you, to reduce errors.
 Creating a branch is not much different from creating a tag, except that the destination URL of the copy must contain branches instead of tag (the source URL can be the trunk or another tag) and the name of the branch should end with a 'b', like v1r2b or v3b. For example:
svn cp svn+ssh://svn.cern.ch/reps/lhcb/Gauss/tags/Gen/EvtGen/v11r10 svn+ssh://svn.cern.ch/reps/lhcb/Gauss/branches/Gen/EvtGen/v11r10b
Line: 234 to 277
 and work as if you checked out the trunk. Note that is your branch name does not end with a 'b', you will have to add the option --branch when calling getpack.
Changed:
<
<

Merging changes across banches

>
>

- Merging changes across banches

 Often, when working with branches, you need to merge in the trunk changes that are on a branch or the other way around.

Let's take the example of a fix that has to be back-ported from the trunk to an old version. Let's assume that the changes you want to back-port are the commits in the trunk after revision 100 up to 110 (included) plus the commit of revision 115.

Line: 271 to 314
 

Subversion documentation

Changed:
<
<

Basic SVN commands

>
>

- Basic SVN commands

 See SVN quick reference card and SVN cheat sheet
Line: 279 to 322
  Some simple instructions to migrate an existing CVS checkout to SVN are available at HowToMigrateACvsCheckoutToSvn.
Changed:
<
<

FAQ

>
>

- FAQ

 

When I try to commit, I get the message "Cannot modify files in tag directories"

I know that I should have the rights to commit, but when I issue the command svn commit src/MuEffMonitor.cpp -m "bla bla" I get the message:
Line: 290 to 333
 svn: Commit blocked by pre-commit hook (exit code 1) with output: Cannot modify files in tag directories
Changed:
<
<
This is because you are not working with the HEAD of the package. You cannot commit to a tag branch, you must commit to the trunk. See the Guidelines for SVN commit
>
>
This is because you are not working with the HEAD of the package. You cannot commit to a tag, you must commit to the trunk or to a branch. See the Guidelines for SVN commit

If necessary the release manager can make a branch for you.

 

When I try to commit, I get the message "svn: This client is too old to work with working copy 'ThePackage'; please get a newer Subversion client"

This is because the last time you worked with ThePackage (getpack or commit) you must have done so from a machine with a more recent SVN client than the one installed on the current machine. This is a longstanding issue in particular with with slc5, which ships with a very old SVN client. You can 'fix' this by issuing the command change-svn-wc-format
Changed:
<
<

Subversion manual

>
>

- Subversion manual

 The complete manual is available from http://svnbook.red-bean.com
Changed:
<
<

Instructions for LHCb librarians

>
>

- Instructions for LHCb librarians

 Instructions for LHCb Subversion librarians are available at SubversionSupport.

-- MarcoClemencic - 15-Dec-2009

Revision 262011-02-11 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial and the FAQ.
Line: 186 to 186
 
    • Fix any packages that were broken by your commit (or ask the package owner to do it)
Deleted:
<
<

Guidelines for tags

 
Added:
>
>

Guidelines for tags

  Users do not need to make tags in SVN, since the revision number provides the same information, but you can, if necessary, or if you are the project manager for example.
Line: 222 to 220
  then re-create the tag with the instructions in the previous section.
Added:
>
>

Working with branches

Creating a branch is not much different from creating a tag, except that the destination URL of the copy must contain branches instead of tag (the source URL can be the trunk or another tag) and the name of the branch should end with a 'b', like v1r2b or v3b. For example:
svn cp svn+ssh://svn.cern.ch/reps/lhcb/Gauss/tags/Gen/EvtGen/v11r10 svn+ssh://svn.cern.ch/reps/lhcb/Gauss/branches/Gen/EvtGen/v11r10b

To work on the branch, just use getpack to check it out (requires LbScripts >= v6r0):

getpack Gen/EvtGen v11r10b
and work as if you checked out the trunk. Note that is your branch name does not end with a 'b', you will have to add the option --branch when calling getpack.

Merging changes across banches

Often, when working with branches, you need to merge in the trunk changes that are on a branch or the other way around.

Let's take the example of a fix that has to be back-ported from the trunk to an old version. Let's assume that the changes you want to back-port are the commits in the trunk after revision 100 up to 110 (included) plus the commit of revision 115. What you have to do to merge is:

cd Gen/EvtGen
svn merge -r 100:110 -c 115 svn+ssh://svn.cern.ch/reps/lhcb/Gauss/trunk/Gen/EvtGen
You can also use the tool svnpath to get URL for the package (see svnpath --help):
cd Gen/EvtGen
svn merge -r 100:110 -c 115 `svnpath Gen/EvtGen`
The exact meaning of -r and -c are described in the help page svn merge -h.

SVN may ask you what to do in case there is a conflict. You can:

  • see the differences (df)
  • edit the conflict (e)
  • keep the version in your working copy (mc, mine-conflict)
  • use the version in the repository (tc, theirs-conflict)
  • flag the conflict as resolved after the edit (r)
  • and more (s, show all options)

Once the merge is completed, just commit the merged version with svn commit.

If the merge has to be done the other way around, i.e. from the branch to the trunk, swap the trunk and the branch:

getpack Gen/EvtGen trunk
cd Get/EvetGen
svn merge `svnpath Gen/EvtGen v11r10b`
svn commit
Note: if you do not specify the revisions to be merged, it will pick up all the changes that have been applied since the branch (or the last merge), so it is better to use this feature when merging from a branch into the trunk.
 

Subversion documentation

Basic SVN commands

Revision 242010-10-01 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial and the FAQ.
Line: 151 to 151
  This will list the files that have changes with respect to the versions in the repository. The type of difference will be marked with one or more letters. The most common are: M for changes in your copy, ? for new files, * for files that have a new version in the repository, C if there are conflicts between your changes and the ones in the repository, ! for files removed. The complete list of letters can be found in the SVN documentation. Once you're sure of your changes, you can call svn update (or svn up) to synchronize the working copy with the changes in repository.
    • Make sure that there is no C in front of any file: C in front of a file means that several people are working on the same package so be careful: SVN has tried to merge your modifications with the changes already done and it has NOT succeeded. Check the merged files carefully: SVN 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 svn update, but you then need to be more careful of what you do.
Changed:
<
<
    • Eliminate any ? in source directories: These are files that you added and that are not in the repository. If you wish to save them in SVN, you have to
>
>
    • Check carefully, and Eliminate or ignore any ? in source directories: These are files that you created newly and that are not in the repository. If you wish to save them in SVN, you have to
 
svn add TheFileToAdd
Line: 165 to 165
 svn update
      • Any C should have been replaced by M
Changed:
<
<
      • Any ? should have been replaced by A
>
>
      • Any ? should have been replaced by A, or just ignored, you may have several ? left
 
      • Any ! should have been replaced by R
    • Finally, commit the package

Revision 232010-09-03 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial and the FAQ.
Line: 241 to 241
  This is because you are not working with the HEAD of the package. You cannot commit to a tag branch, you must commit to the trunk. See the Guidelines for SVN commit
Added:
>
>

When I try to commit, I get the message "svn: This client is too old to work with working copy 'ThePackage'; please get a newer Subversion client"

This is because the last time you worked with ThePackage (getpack or commit) you must have done so from a machine with a more recent SVN client than the one installed on the current machine. This is a longstanding issue in particular with with slc5, which ships with a very old SVN client. You can 'fix' this by issuing the command change-svn-wc-format
 

Subversion manual

The complete manual is available from http://svnbook.red-bean.com

Revision 222010-07-30 - AnatolySolomin

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial and the FAQ.
Line: 150 to 150
  This will list the files that have changes with respect to the versions in the repository. The type of difference will be marked with one or more letters. The most common are: M for changes in your copy, ? for new files, * for files that have a new version in the repository, C if there are conflicts between your changes and the ones in the repository, ! for files removed. The complete list of letters can be found in the SVN documentation. Once you're sure of your changes, you can call svn update (or svn up) to synchronize the working copy with the changes in repository.
Changed:
<
<
    • 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: SVN has tried to merge your modifications with the changes already done and it has NOT succeeded. Check the merged files carefully: SVN 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 svn update, 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 SVN, you have to
>
>
    • Make sure that there is no C in front of any file: C in front of a file means that several people are working on the same package so be careful: SVN has tried to merge your modifications with the changes already done and it has NOT succeeded. Check the merged files carefully: SVN 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 svn update, but you then need to be more careful of what you do.
    • Eliminate any ? in source directories: These are files that you added and that are not in the repository. If you wish to save them in SVN, you have to
 
svn add TheFileToAdd
Changed:
<
<
do not add any file in the cmt/ directory, or any copy of a file that should not be kept (e.g. files whose name ends with "~")
    • Tell RVN 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
>
>
but do not add any file in the cmt/ directory, or any copy of a file that should not be kept (e.g. files whose name ends with "~")
    • Tell SVN 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 SVN, issue the comand
 
svn rm TheFileToRemove

Revision 212010-07-19 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial and the FAQ.
Line: 140 to 140
 
svn switch svn+ssh://svn.cern.ch/reps/lhcb/Rec/trunk/Tf/PatAlgorithms
Added:
>
>
    • An alternative is to call getpack again on the same package asking for version trunk from the parent directory:
      getpack Tf/PatAlgorithms trunk
      
 
  • Check what you are about to commit against the repository:
    svn status -u

Revision 202010-07-13 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Changed:
<
<
The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
>
>
The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial and the FAQ.
  For instructions about the usage of the CVS repository, look at CVSUsageGuidelines.
Line: 12 to 12
 

Table of Contents

Deleted:
<
<

Accessing Subversion

 
Added:
>
>

Accessing Subversion

 

Web access

  • The LHCb, Gaudi and Dirac repositories are world readable and browsable via the two web interfaces and a statistics page
    • LHCb:
Line: 114 to 114
 

Creating a new package

If you wish to create a new package and add it to Subversion, follow the guidelines in CreateNewPackageSVN.
Deleted:
<
<

Guidelines for SVN commit

 
Added:
>
>

Guidelines for SVN 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:
Line: 128 to 128
 
      • 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)
      ! 2009-12-15 - Marco Clemencic
      - This is the comment for the latest commit, do not touch anything below this line.


      !================== GaudiConf v10r9 2008-06-04 ========================
Changed:
<
<
  • Switch to a directory where you will be able to commit (equivalent of the old cvs update -A preparation before committing):
    • Since TAGGED directories are not supposed to be altered, when committing a change to a package you should, before switch to the trunk directory. To do so you should
      • Issue the command
        svn info
        
        That will tell you the actual path of your package.
>
>
  • If you are not working with the HEAD revision of a package (i.e. you checked out and modified a tagged version), switch to a directory where you will be able to commit (equivalent of the old cvs update -A preparation before committing):
    • Since TAGGED directories are not supposed to be altered, when committing a change to a package you should, first, switch to the trunk directory. To do so you should
      • Issue the command svn info. That will tell you the actual path of your package:
 
svn info
Path: .
URL: svn+ssh://svn.cern.ch/reps/lhcb/Rec/tags/Tf/PatAlgorithms/v3r29
Changed:
<
<
      • This needs to be altered in order to include trunk in place of tags. You also need to remove the specifc tag at the end of the package. Then you can swith to the new URL with the svn switch command:
>
>
      • If the URL is of the form above (i.e. it contains the tags subdirectory and a version number), it means you are working against a tagged version. This needs to be altered in order to include trunk in place of tags. You also need to remove the version number at the end of the URL. Do this with the svn switch command:
 
svn switch svn+ssh://svn.cern.ch/reps/lhcb/Rec/trunk/Tf/PatAlgorithms
Line: 227 to 223
 A summary of SVN commands for CVS users can be found in the Gaudi twiki.

Some simple instructions to migrate an existing CVS checkout to SVN are available at HowToMigrateACvsCheckoutToSvn.

Added:
>
>

FAQ

When I try to commit, I get the message "Cannot modify files in tag directories"

I know that I should have the rights to commit, but when I issue the command svn commit src/MuEffMonitor.cpp -m "bla bla" I get the message:
==>>
Sending        src/MuEffMonitor.cpp
Transmitting file data ....svn: Commit faild (details follow):
svn: Commit blocked by pre-commit hook (exit code 1) with output:
Cannot modify files in tag directories
This is because you are not working with the HEAD of the package. You cannot commit to a tag branch, you must commit to the trunk. See the Guidelines for SVN commit
 

Subversion manual

The complete manual is available from http://svnbook.red-bean.com

Revision 192010-07-12 - unknown

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
Line: 128 to 128
 
      • 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)
      ! 2009-12-15 - Marco Clemencic
      - This is the comment for the latest commit, do not touch anything below this line.


      !================== GaudiConf v10r9 2008-06-04 ========================
Changed:
<
<
  • Switch to a directory where you will be able to commit:
>
>
  • Switch to a directory where you will be able to commit (equivalent of the old cvs update -A preparation before committing):
 
    • Since TAGGED directories are not supposed to be altered, when committing a change to a package you should, before switch to the trunk directory. To do so you should
      • Issue the command

Revision 182010-07-12 - unknown

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
Line: 128 to 128
 
      • 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)
      ! 2009-12-15 - Marco Clemencic
      - This is the comment for the latest commit, do not touch anything below this line.


      !================== GaudiConf v10r9 2008-06-04 ========================
Added:
>
>
  • Switch to a directory where you will be able to commit:
    • Since TAGGED directories are not supposed to be altered, when committing a change to a package you should, before switch to the trunk directory. To do so you should
      • Issue the command
        svn info
        
        That will tell you the actual path of your package.
        svn info
        Path: .
        URL: svn+ssh://svn.cern.ch/reps/lhcb/Rec/tags/Tf/PatAlgorithms/v3r29
        
      • This needs to be altered in order to include trunk in place of tags. You also need to remove the specifc tag at the end of the package. Then you can swith to the new URL with the svn switch command:
        svn switch svn+ssh://svn.cern.ch/reps/lhcb/Rec/trunk/Tf/PatAlgorithms
        
 
  • Check what you are about to commit against the repository:
    svn status -u

Revision 172010-06-24 - ChristopherRJones

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
Line: 77 to 77
 

Kerberos authentication (Linux/MacOSX)

It is possible to use the Kerberos V token to connect to the Subversion server instead of the ssh key, simply modifying the content of the .ssh/config file as
Changed:
<
<
Host svn.cern.ch svn
>
>
Host svn.cern.ch
  User myusername GSSAPIAuthentication yes GSSAPIDelegateCredentials yes

Revision 162010-05-10 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
Line: 140 to 140
 svn add TheFileToAdd do not add any file in the cmt/ directory, or any copy of a file that should not be kept (e.g. files whose name ends with "~")
Changed:
<
<
    • 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
>
>
    • Tell RVN 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
 
svn rm TheFileToRemove
Line: 160 to 160
 
svn commit -m "some brief and meaningful comment"
Changed:
<
<
  • If the package is part of a production project, like Rec, Phys, Analysis etc. then you should add it to the LHCbTagCollector so that the release manager will know what to do with your changes for the release. Use as "tag" the revision number that was printed by svn after the commit. You do not need to provide a "user tag" as was done for CVS. If you do want to provide your own tag, please follow the guidelines for tags
>
>
  • If the package is part of a production project, like Rec, Phys, Analysis etc. then you should add it to the LHCbTagCollector so that the release manager will know what to do with your changes for the release. Use as "tag" the revision number that was printed by svn after the commit. You do not need to provide a "user tag" as was done for CVS. If you do want to provide your own tag, please follow the guidelines for 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)
Line: 170 to 170
 

Guidelines for tags

Added:
>
>
Users do not need to make tags in SVN, since the revision number provides the same information, but you can, if necessary, or if you are the project manager for example.
 Tagging in Subversion, if you are used to another version control system, may appear strange. The concept of tag and branch are not available in Subversion, but they can be easily emulated using a convention, thanks to the ability of Subversion of remembering the history of the whole repository (including directories).

The standard convention used in almost all the projects hosted on Subversion (a notable exception being CMT) is based on the presence of three directories called trunk, tags and branches. The trunk contains the main line of development of your code. tags and branches contains copies of the trunk with symbolic names (like v1r2 or 2.3.4). There is no technical difference between tags and branches, but the convention is that you are not supposed to commit changes to a file in the tags directory.

Revision 152010-05-01 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
Line: 202 to 202
 

Subversion documentation

Basic SVN commands

Changed:
<
<
A list of basic SVN commands can be downloaded from http://ariejan.net/svncheatsheet.
>
>
See SVN quick reference card and SVN cheat sheet
  A summary of SVN commands for CVS users can be found in the Gaudi twiki.

Revision 132010-04-03 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
Line: 156 to 156
 
svn commit -m "some brief and meaningful comment"
Changed:
<
<
  • If you would like your commit included in the next official release, add an entry to the LHCbTagCollector using as "tag" the revision number that was printed by svn after the commit. You do not need to provide a "user tag" as was done for CVS. If you do want to provide your own tag, please follow the guidelines for tags
>
>
  • If the package is part of a production project, like Rec, Phys, Analysis etc. then you should add it to the LHCbTagCollector so that the release manager will know what to do with your changes for the release. Use as "tag" the revision number that was printed by svn after the commit. You do not need to provide a "user tag" as was done for CVS. If you do want to provide your own tag, please follow the guidelines for 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)
Changed:
<
<
If the package is part of a production project, like Rec, Phys, Analysis etc. then you should add it to the LHCbTagCollector so that the release manager will know what to do with your changes for the release.
>
>
 

Guidelines for tags

Revision 122010-03-19 - RobLambert

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
Line: 161 to 161
 
    • 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)
Added:
>
>
If the package is part of a production project, like Rec, Phys, Analysis etc. then you should add it to the LHCbTagCollector so that the release manager will know what to do with your changes for the release.
 

Guidelines for tags

Tagging in Subversion, if you are used to another version control system, may appear strange. The concept of tag and branch are not available in Subversion, but they can be easily emulated using a convention, thanks to the ability of Subversion of remembering the history of the whole repository (including directories).

Revision 112010-02-20 - ChristopherRJones

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Changed:
<
<
The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
>
>
The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
  For instructions about the usage of the CVS repository, look at CVSUsageGuidelines.
Line: 30 to 30
 

Installing the Subversion client

The Subversion command line client svn is available in all Linux distributions with names like subversion or subversion-client. It is available by default on lxplus5 nodes, but it might not be installed on other machines, but you can easily find on the web how to install it for your distribution.
Changed:
<
<
For Windows, MacOS (and for Linux distributions that do not have it packaged) you can find the sources and pre-compiled distributions linked from the official Subversion web site.
>
>
For Windows, MacOS (and for Linux distributions that do not have it packaged) you can find the sources and pre-compiled distributions linked from the official Subversion web site.
 
Changed:
<
<
Several graphic clients to Subversion are available too.
>
>
Several graphic clients to Subversion are available too. RapidSVN is a half decent free application and available on many platforms.
  On the LHCb Windows Terminal Server we install the CollabNet command line client and the TortoiseSVN graphic client (a command line client is mandatory to be able to use getpack).
Line: 70 to 70
  To be noted that this procedure for the setting of the user name prevents the explicit embedding of the user name in the URL of the repository. There is a problem in the release areas and distribution kits if a given user name is hard-coded in the URL. There should be no explicit user name.
Changed:
<
<

Kerberos authentication (Linux/!MacOSX)

>
>

Kerberos authentication (Linux/MacOSX)

 It is possible to use the Kerberos V token to connect to the Subversion server instead of the ssh key, simply modifying the content of the .ssh/config file as
Host svn.cern.ch svn

Revision 102010-02-10 - PatrickSKoppenburg

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

Changed:
<
<
The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport.
>
>
The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport. Also look at Marco's svn tutorial.
  For instructions about the usage of the CVS repository, look at CVSUsageGuidelines.

Revision 82010-01-20 - MarcoCattaneo

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport.
Line: 155 to 155
 
svn commit -m "some brief and meaningful comment"
Changed:
<
<
  • Add an entry to the LHCbTagCollector using the number that was printed by svn after the commit as reference. If you want to use a "user tag" as it was done with CVS, follow the guidelines for tags
>
>
  • If you would like your commit included in the next official release, add an entry to the LHCbTagCollector using as "tag" the revision number that was printed by svn after the commit. You do not need to provide a "user tag" as was done for CVS. If you do want to provide your own tag, please follow the guidelines for 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)
Line: 179 to 179
  See GaudiSVNRepository for a description of the tags conventions in the LHCb Subversion repository.
  • Do not use an official tag of the form vxry
Deleted:
<
<
  • 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

Modifying the content of a tag is always a bad policy.

Revision 72010-01-05 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport.
Line: 105 to 105
  For backward compatibility with the pre-svn version of getpack, if the environment variable GETPACK_USER is defined, getpack will embed the value of that variable in the URL when checking out the code. Since it is not a good idea, check that you do not set that variable and use the above instructions to use the correct username when accessing the repository.
Changed:
<
<

Guidelines for CVS actions in LHCb

>
>

Guidelines for SVN actions in LHCb

 

Creating a new package

If you wish to create a new package and add it to Subversion, follow the guidelines in CreateNewPackageSVN.
Changed:
<
<

Guidelines for CVS commit

>
>

Guidelines for SVN 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.
Line: 199 to 199
  A summary of SVN commands for CVS users can be found in the Gaudi twiki.
Added:
>
>
Some simple instructions to migrate an existing CVS checkout to SVN are available at HowToMigrateACvsCheckoutToSvn.
 

Subversion manual

The complete manual is available from http://svnbook.red-bean.com

Revision 62009-12-18 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport.
Line: 45 to 45
 to the [tunnels] section of the subversion client configuration file (either the user or the global one), see the Subversion book for details.

Getting write access

Changed:
<
<
To get write access to LHCb Subversion repository, go to the e-group lhcb-svn-librarians and register the account you want to use when accessing the Subversion repository. A mail will be sent automatically to the librarians that will add you to the group.
>
>
To get write access to LHCb Subversion repository, go to the e-group lhcb-svn-writers and register the account you want to use when accessing the Subversion repository. A mail will be sent automatically to the librarians that will add you to the group.

Note that when you register to the e-group lhcb-svn-writers, you will receive the emails sent on the lhcb-core-soft mailing list.

 

Connecting with a different user name

For windows, it is quite simple. You just have to change the autologin name in the "svn.cern.ch" session. You can do it by loading the session in putty and change the username in the Connection->Data section as described in the CERN SVN How-To.
Line: 153 to 155
 
svn commit -m "some brief and meaningful comment"
Changed:
<
<
>
>
  • Add an entry to the LHCbTagCollector using the number that was printed by svn after the commit as reference. If you want to use a "user tag" as it was done with CVS, follow the guidelines for 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)

Revision 52009-12-16 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport.
Line: 44 to 44
  to the [tunnels] section of the subversion client configuration file (either the user or the global one), see the Subversion book for details.
Changed:
<
<

Setting up write access

To get write access to LHCb Subversion repository:
  • Ask the LHCb Subversion librarian: Hubert Degaudenzi, or one of his deputies: Marco Clemencic
  • 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
>
>

Getting write access

To get write access to LHCb Subversion repository, go to the e-group lhcb-svn-librarians and register the account you want to use when accessing the Subversion repository. A mail will be sent automatically to the librarians that will add you to the group.
 

Connecting with a different user name

For windows, it is quite simple. You just have to change the autologin name in the "svn.cern.ch" session. You can do it by loading the session in putty and change the username in the Connection->Data section as described in the CERN SVN How-To.

Revision 42009-12-16 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport.
Line: 89 to 89
  as explained in the SVN How-To.
Changed:
<
<

Modifications in getpack

>
>

getpack

 After these settings, you are able to get the code (check out) from the repository:
Changed:
<
<
svn co svn+ssh://svn.cern.ch/reps/lhcb/MyPackage
>
>
svn co svn+ssh://svn.cern.ch/reps/lhcb/AProject/trunk/MyPackage
 
Changed:
<
<
on Linux, MacOSX or Windows. This is not however the usual checkout tool used in LHCb. The getpack utility is used for a plain checkout but it is also able to do a recursive checkout according to the CMT dependency.
>
>
svn co svn+ssh://svn.cern.ch/reps/lhcb/AProject/tags/MyPackage/v2r3 MyPackage
on Linux, MacOSX or Windows, however, this is not however the usual way we check out packages in LHCb.
 
Changed:
<
<
Note that to be able to use the getpack script you must be able to connect correctly to the svn repository without being asked for the password, so be sure that you have the correct configuration explained above.
>
>
The tool getpack simplifies users' life taking care of details like the presence of several repositories and the project that contains the package. It is also able to do a recursive checkout according to the CMT dependency.
 
Changed:
<
<
For backward compatibility with the pre-svn version of getpack, if the environment variable GETPACK_USER is defined, getpack will embed the value of that variable in the URL when checking out the code. Since it is not a good idea, check that you do not set that variable and use the above instructions to use the correct username when accessing the repository.
>
>
Note that to be able to use getpack you must be able to connect correctly to the Subversion repository without being asked for the password, so be sure that you have the correct configuration explained above.

For backward compatibility with the pre-svn version of getpack, if the environment variable GETPACK_USER is defined, getpack will embed the value of that variable in the URL when checking out the code. Since it is not a good idea, check that you do not set that variable and use the above instructions to use the correct username when accessing the repository.

 

Guidelines for CVS actions in LHCb

Creating a new package

Line: 154 to 159
 
  • 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)
Added:
>
>
 

Guidelines for tags

Changed:
<
<
These guidelines were presented on 18th June 2008 (33rd LHCb software week)
>
>
Tagging in Subversion, if you are used to another version control system, may appear strange. The concept of tag and branch are not available in Subversion, but they can be easily emulated using a convention, thanks to the ability of Subversion of remembering the history of the whole repository (including directories).

The standard convention used in almost all the projects hosted on Subversion (a notable exception being CMT) is based on the presence of three directories called trunk, tags and branches. The trunk contains the main line of development of your code. tags and branches contains copies of the trunk with symbolic names (like v1r2 or 2.3.4). There is no technical difference between tags and branches, but the convention is that you are not supposed to commit changes to a file in the tags directory.

The convention used for the repository layout in LHCb is described in detail in GaudiSVNRepository.

The guidelines for tagging in LHCb were presented on 18th June 2008 (33rd LHCb software week)

 
  • It is recommended to use a tag of the form <username>_<yyyymmdd> where <yyyymmdd> is the date of the commit. If you have to create more than one user tag during the day, you can append a lowercase letter (starting from a) to distinguish them. To tag the repository as of a certain date (e.g. now) do (note: you can use svn info | awk '/^URL/{print $2}' to get the URL of the package you are using)
    svn cp svn+ssh://svn.cern.ch/reps/lhcb/Brunel/trunk/Rec/Brunel svn+ssh://svn.cern.ch/reps/lhcb/Brunel/tags/Rec/Brunel/marcocle_20091215

Revision 32009-12-16 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport.
Line: 127 to 127
 
    • 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: SVN has tried to merge your modifications with the changes already done and it has NOT succeeded. Check the merged files carefully: SVN 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 svn update, 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 SVN, you have to

Changed:
<
<
svn add TheFiletoAdd
>
>
svn add TheFileToAdd
  do not add any file in the cmt/ directory, or any copy of a file that should not be kept (e.g. files whose name ends with "~")
    • 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

Revision 22009-12-15 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport.
Line: 26 to 26
  The layout of the repository is based on the rules outlined in the Gaudi twiki.
Changed:
<
<

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

The LHCb CVS repository resides on the CERN/IT CVS server. Access is world read if you are already authenticated, typically Kerberos (AFS) authentication on Linux, ssh authentication (how?) on Windows. To access the repository, set up the following environment variables:
  • Linux:
CVSROOT = :ext:isscvs.cern.ch:/local/reps/lhcb
  • Windows:
CVSROOT = :ext:isscvs.cern.ch:/local/reps/lhcb
CVS_RSH = C:\Program Files\PuTTY\plink

Setting up write access

To get write access to LHCb CVS repository:
  • 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)

From the beginning of 2009, the CERN IT is removing the support for the Kerberos IV authentication method. This has some side effects on way to connect to the CVS servers and the "kserver" (Kerberos IV) method cannot be used anymore on Linux. The CVS client has still to be installed as described here. It has been decided to move globally to the "ext" (ssh) method instead of the "gserver" (Kerberos V) method. It has the advantage to be the same on Linux, Windows and MacOS and it doesn't require to have a special patched version of the CVS client. For details on how to setup SSH access on UNIX systems, see here.
>
>

Installing the Subversion client

The Subversion command line client svn is available in all Linux distributions with names like subversion or subversion-client. It is available by default on lxplus5 nodes, but it might not be installed on other machines, but you can easily find on the web how to install it for your distribution.

For Windows, MacOS (and for Linux distributions that do not have it packaged) you can find the sources and pre-compiled distributions linked from the official Subversion web site.

 
Changed:
<
<
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.
>
>
Several graphic clients to Subversion are available too.
 
Changed:
<
<
The following instructions are detailing the various settings for CVS on standalone or external boxes. Please read them carefully.
>
>
On the LHCb Windows Terminal Server we install the CollabNet command line client and the TortoiseSVN graphic client (a command line client is mandatory to be able to use getpack).
 

Setting up read access

Changed:
<
<
To access the repository, set up the following environment variables in order to use ssh:
  • Linux and MacOS:
CVSROOT = :ext:isscvs.cern.ch:/local/reps/lhcb
CVS_RSH = ssh
  • Windows:
CVSROOT = :ext:isscvs.cern.ch:/local/reps/lhcb
CVS_RSH = C:\Program Files\PuTTY\plink
>
>
Detailed instructions about how to configure the access to the Subversion repository are provided by IT in the SVN How-To. You can find instructions for Linux and Windows.

Note: To enable the ssh tunnel for the command line client on Windows (URLs of the form svn+ssh://), you may need to add the line

ssh = $SVN_RSH "C:/Program Files/TortoiseSVN/bin/TortoisePlink.exe"
to the [tunnels] section of the subversion client configuration file (either the user or the global one), see the Subversion book for details.

Setting up write access

To get write access to LHCb Subversion repository:
  • Ask the LHCb Subversion librarian: Hubert Degaudenzi, or one of his deputies: Marco Clemencic
  • 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
 
Deleted:
<
<
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 :
"C:\Program Files\PuTTY\putty" isscvs.cern.ch
 

Connecting with a different user name

Changed:
<
<
For windows, it is quite simple. You just have to change the autologin name in the "isscvs.cern.ch" session. You can do it by loading the session in putty and change the username in the Connection->Data section as above.
>
>
For windows, it is quite simple. You just have to change the autologin name in the "svn.cern.ch" session. You can do it by loading the session in putty and change the username in the Connection->Data section as described in the CERN SVN How-To.
 
Changed:
<
<
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:
>
>
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 svn.cern.ch should look like:
 
Changed:
<
<
Host isscvs.cern.ch
>
>
Host svn.cern.ch svn
  User myusername Protocol 2 ForwardX11 no IdentityFile ~/.ssh/id_rsa
Changed:
<
<
Host svn.cern.ch
>
>
Host isscvs.cern.ch
  User myusername Protocol 2 ForwardX11 no IdentityFile ~/.ssh/id_rsa
Changed:
<
<
where "myusername" is the name you want to use for the ssh authentication. Note that the entry for svn.cern.ch is needed since the latest getpack also queries this server.
>
>
where "myusername" is the name you want to use for the ssh authentication. Note that the entry for isscvs.cern.ch is needed since the latest getpack also queries this server.
 
Changed:
<
<
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

Moving from the kerberos method for ssh doesn't mean that it cannot be used at all. on Linux/MacOSX The Kerberos V token can still be used for the ssh authentication. It is forwarded to ssh which then creates the "ext" connection to the CVS server and this is the default at CERN on the lxplus cluster. On other machine or cluster (or external to CERN), you have to obtain your token from the CERN Kerberos domain and setup your ssh entry like:
Host isscvs.cern.ch
    GSSAPIAuthentication yes
    Protocol  2
    ForwardX11 no

Modifications in getpack

After these settings, you are able to do a plain CVS source code extraction
cvs co MyPackage
on Linux, MacOSX or Windows. This is not however the usual checkout tool used in LHCb. The getpack utility is used for a plain checkout but it is also able to do a recursive checkout according to the CMT dependency.
>
>
To be noted that this procedure for the setting of the user name prevents the explicit embedding of the user name in the URL of the repository. There is a problem in the release areas and distribution kits if a given user name is hard-coded in the URL. There should be no explicit user name.
 
Changed:
<
<
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.
>
>

Kerberos authentication (Linux/!MacOSX)

It is possible to use the Kerberos V token to connect to the Subversion server instead of the ssh key, simply modifying the content of the .ssh/config file as
Host svn.cern.ch svn
   User myusername
   GSSAPIAuthentication yes
   GSSAPIDelegateCredentials yes
   Protocol 2
   ForwardX11 no
   IdentityFile ~/.ssh/id_rsa
Host isscvs.cern.ch
   User myusername    
   GSSAPIAuthentication yes
   GSSAPIDelegateCredentials yes
   Protocol 2
   ForwardX11 no
   IdentityFile ~/.ssh/id_rsa
as explained in the SVN How-To.
 
Changed:
<
<
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.
>
>

Modifications in getpack

After these settings, you are able to get the code (check out) from the repository:
svn co svn+ssh://svn.cern.ch/reps/lhcb/MyPackage
on Linux, MacOSX or Windows. This is not however the usual checkout tool used in LHCb. The getpack utility is used for a plain checkout but it is also able to do a recursive checkout according to the CMT dependency.
 
Changed:
<
<

Converting the already checked out software sources

For the source code packages which have been checkout with the old "kserver" method (you can check in the CVS/Root file), they have to be converted to use the new method. The CERN IT is providing a migration tool for this:
/afs/cern.ch/project/cvs/dist/bin/move2ssh
This script has been run on the AFS LHCb release areas and it is recommended that you run it on your own checkout software sources (most of the time in the ~/cmtuser directory). This script has also been added for convenience in the $LHCBSCRIPTS directory.
>
>
Note that to be able to use the getpack script you must be able to connect correctly to the svn repository without being asked for the password, so be sure that you have the correct configuration explained above.
 
Changed:
<
<
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.
>
>
For backward compatibility with the pre-svn version of getpack, if the environment variable GETPACK_USER is defined, getpack will embed the value of that variable in the URL when checking out the code. Since it is not a good idea, check that you do not set that variable and use the above instructions to use the correct username when accessing the repository.
 

Guidelines for CVS actions in LHCb

Creating a new package

Changed:
<
<
If you wish to create a new package and add it to CVS, follow the guidelines given here
>
>
If you wish to create a new package and add it to Subversion, follow the guidelines in CreateNewPackageSVN.
 

Guidelines for CVS commit

Line: 103 to 110
 
    • 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
Changed:
<
<
      • Increment the major version ( v) if the change is backward incompatible (change in interfaces, major change in behaviour)
>
>
      • Increment the major version (v) if the change is backward incompatible (change in interfaces, major change in behavior)
 
      • 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)
Changed:
<
<
! 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 ========================
>
>
! 2009-12-15 - Marco Clemencic
- 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:
Changed:
<
<
cvs -n update -A
This will list the actions that CVS will perform without actually applying any change (-n), identifying your modifications with M, any new files with ?, any files changed on the CVS repository since your last checkout with U, any files changed on the CVS repository and also modified by you with C, and any files removed by you but existing in CVS as lost. Once you're sure of your changes, you can call the same command again without the (-n) option.
    • 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
cvs add TheFiletoAdd
>
>
svn status -u
This will list the files that have changes with respect to the versions in the repository. The type of difference will be marked with one or more letters. The most common are: M for changes in your copy, ? for new files, * for files that have a new version in the repository, C if there are conflicts between your changes and the ones in the repository, ! for files removed. The complete list of letters can be found in the SVN documentation. Once you're sure of your changes, you can call svn update (or svn up) to synchronize the working copy with the changes in 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: SVN has tried to merge your modifications with the changes already done and it has NOT succeeded. Check the merged files carefully: SVN 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 svn update, 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 SVN, you have to
      svn add !TheFiletoAdd
      
  do not add any file in the cmt/ directory, or any copy of a file that should not be kept (e.g. files whose name ends with "~")
Deleted:
<
<
 
    • 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
Changed:
<
<
cvs rm TheFileToRemove
>
>
svn rm TheFileToRemove
 
    • Check again the package:
Changed:
<
<
cvs update
      • Any C should have been replaced by M
      • Any ? should have been replaced by A
      • Any lost should have been replaced by R
>
>
svn update
      • Any C should have been replaced by M
      • Any ? should have been replaced by A
      • Any ! should have been replaced by R
 
    • Finally, commit the package
Changed:
<
<
cvs commit -m "some brief and meaningful one line comment"
>
>
svn commit
Always add a meaningful comment using the editor that is automatically started.
You can by-pass the editor with the -m switch:
svn commit -m "some brief and meaningful comment"
 
  • 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)
Changed:
<
<

Guidelines for CVS tag

These guidelines were presented on 18th June 2008 (33rd LHCb software week)
  • 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
cvs rtag cattanem_20080620 Rec/Brunel
>
>

Guidelines for tags

These guidelines were presented on 18th June 2008 (33rd LHCb software week)
  • It is recommended to use a tag of the form <username>_<yyyymmdd> where <yyyymmdd> is the date of the commit. If you have to create more than one user tag during the day, you can append a lowercase letter (starting from a) to distinguish them. To tag the repository as of a certain date (e.g. now) do (note: you can use svn info | awk '/^URL/{print $2}' to get the URL of the package you are using)
    svn cp svn+ssh://svn.cern.ch/reps/lhcb/Brunel/trunk/Rec/Brunel svn+ssh://svn.cern.ch/reps/lhcb/Brunel/tags/Rec/Brunel/marcocle_20091215
    
 or to tag according to what's presently in your directory, do in your directory (e.g. Rec/Brunel):
Changed:
<
<
cvs tag pkoppenb_20080620
See section 4.6 of the cvs user guide for details.
>
>
svn cp . svn+ssh://svn.cern.ch/reps/lhcb/Brunel/tags/Rec/Brunel/marcocle_20091215
See GaudiSVNRepository for a description of the tags conventions in the LHCb Subversion repository.
 
  • 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

Changed:
<
<
It is likely at some point you will tag a package, only to discover you have forgotten to commit a change to CVS beforehand. In this case the best thing to do is to remove the tag, make the missing changes and then retag. E.g. remove the tag theTag
cvs rtag -d theTag Det/RichDet
make your changes, and then tag again
cvs rtag theTag Det/RichDet
This also works with cvs tag. You can also do it in one step by Forcing the tag,
cvs rtag -F theTag Det/RichDet
but this is only safe if you have not removed any files. If you have removed files, the -F does not remove the tag from the files that have been moved to the CVS archive, so if you later checkout theTag you will get back the removed files. It is recommended to use the first method in this case.

CVS documentation

Basic CVS commands

A list of basic CVS commands is described here

CVS manual

The complete manual is available from ximbiot.com
>
>
Modifying the content of a tag is always a bad policy.

If you really have to do it because after a tag you realized you forgot to do a commit and it is a "user tag" then it is better to create a new tag.

To retag you have to delete the tag you created with something like:

svn rm svn+ssh://svn.cern.ch/reps/lhcb/Brunel/tags/Rec/Brunel/marcocle_20091215
then re-create the tag with the instructions in the previous section.

Subversion documentation

Basic SVN commands

A list of basic SVN commands can be downloaded from http://ariejan.net/svncheatsheet.

A summary of SVN commands for CVS users can be found in the Gaudi twiki.

Subversion manual

The complete manual is available from http://svnbook.red-bean.com
 

Instructions for LHCb librarians

Changed:
<
<
Instructions for LHCb CVS librarians are available here
>
>
Instructions for LHCb Subversion librarians are available at SubversionSupport.
  -- MarcoClemencic - 15-Dec-2009
Added:
>
>
META FILEATTACHMENT attachment="svncheatsheet-1.0.1.pdf" attr="" comment="" date="1260899644" name="svncheatsheet-1.0.1.pdf" path="svncheatsheet-1.0.1.pdf" size="73590" stream="svncheatsheet-1.0.1.pdf" tmpFilename="/usr/tmp/CGItemp44106" user="clemenci" version="1"

Revision 12009-12-15 - MarcoClemencic

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="LHCbComputing"

Using Subversion (svn) in LHCb

The LHCb code is kept in a Subversion repository (currently being migrated from CVS). This page is intended for LHCb Subversion users. Instructions for LHCb Subversion librarians are available on SubversionSupport.

For instructions about the usage of the CVS repository, look at CVSUsageGuidelines.

Table of Contents

Accessing Subversion

Web access

The layout of the repository is based on the rules outlined in the Gaudi twiki.

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

The LHCb CVS repository resides on the CERN/IT CVS server. Access is world read if you are already authenticated, typically Kerberos (AFS) authentication on Linux, ssh authentication (how?) on Windows. To access the repository, set up the following environment variables:
  • Linux:
CVSROOT = :ext:isscvs.cern.ch:/local/reps/lhcb
  • Windows:
CVSROOT = :ext:isscvs.cern.ch:/local/reps/lhcb
CVS_RSH = C:\Program Files\PuTTY\plink

Setting up write access

To get write access to LHCb CVS repository:
  • 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)

From the beginning of 2009, the CERN IT is removing the support for the Kerberos IV authentication method. This has some side effects on way to connect to the CVS servers and the "kserver" (Kerberos IV) method cannot be used anymore on Linux. The CVS client has still to be installed as described here. It has been decided to move globally to the "ext" (ssh) method instead of the "gserver" (Kerberos V) method. It has the advantage to be the same on Linux, Windows and MacOS and it doesn't require to have a special patched version of the CVS client. For details on how to setup SSH access on UNIX systems, see 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

To access the repository, set up the following environment variables in order to use ssh:
  • Linux and MacOS:
CVSROOT = :ext:isscvs.cern.ch:/local/reps/lhcb
CVS_RSH = ssh
  • Windows:
CVSROOT = :ext:isscvs.cern.ch:/local/reps/lhcb
CVS_RSH = C:\Program Files\PuTTY\plink

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 :

"C:\Program Files\PuTTY\putty" isscvs.cern.ch

Connecting with a different user name

For windows, it is quite simple. You just have to change the autologin name in the "isscvs.cern.ch" session. You can do it by loading the session in putty and change the username in the Connection->Data section as above.

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
where "myusername" is the name you want to use for the ssh authentication. Note that the entry for svn.cern.ch is needed since the latest getpack also queries this server.

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

Moving from the kerberos method for ssh doesn't mean that it cannot be used at all. on Linux/MacOSX The Kerberos V token can still be used for the ssh authentication. It is forwarded to ssh which then creates the "ext" connection to the CVS server and this is the default at CERN on the lxplus cluster. On other machine or cluster (or external to CERN), you have to obtain your token from the CERN Kerberos domain and setup your ssh entry like:
Host isscvs.cern.ch
    GSSAPIAuthentication yes
    Protocol  2
    ForwardX11 no

Modifications in getpack

After these settings, you are able to do a plain CVS source code extraction
cvs co MyPackage
on Linux, MacOSX or Windows. This is not however the usual checkout tool used in LHCb. The getpack utility is used for a plain checkout but it is also able to do a recursive checkout according to the CMT dependency.

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

For the source code packages which have been checkout with the old "kserver" method (you can check in the CVS/Root file), they have to be converted to use the new method. The CERN IT is providing a migration tool for this:
/afs/cern.ch/project/cvs/dist/bin/move2ssh
This script has been run on the AFS LHCb release areas and it is recommended that you run it on your own checkout software sources (most of the time in the ~/cmtuser directory). This script has also been added for convenience in the $LHCBSCRIPTS directory.

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

If you wish to create a new package and add it to CVS, follow the guidelines given here

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:
cvs -n update -A
This will list the actions that CVS will perform without actually applying any change (-n), identifying your modifications with M, any new files with ?, any files changed on the CVS repository since your last checkout with U, any files changed on the CVS repository and also modified by you with C, and any files removed by you but existing in CVS as lost. Once you're sure of your changes, you can call the same command again without the (-n) option.
    • 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
cvs add TheFiletoAdd
do not add any file in the cmt/ directory, or any copy of a file that should not be kept (e.g. files whose name ends with "~")
    • 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
cvs rm TheFileToRemove
    • Check again the package:
cvs update
      • 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
cvs commit -m "some brief and meaningful one line comment"
  • 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

These guidelines were presented on 18th June 2008 (33rd LHCb software week)
  • 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
cvs rtag cattanem_20080620 Rec/Brunel
or to tag according to what's presently in your directory, do in your directory (e.g. Rec/Brunel):
cvs tag pkoppenb_20080620
See section 4.6 of the cvs user guide for details.

  • 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

It is likely at some point you will tag a package, only to discover you have forgotten to commit a change to CVS beforehand. In this case the best thing to do is to remove the tag, make the missing changes and then retag. E.g. remove the tag theTag
cvs rtag -d theTag Det/RichDet
make your changes, and then tag again
cvs rtag theTag Det/RichDet
This also works with cvs tag. You can also do it in one step by Forcing the tag,
cvs rtag -F theTag Det/RichDet
but this is only safe if you have not removed any files. If you have removed files, the -F does not remove the tag from the files that have been moved to the CVS archive, so if you later checkout theTag you will get back the removed files. It is recommended to use the first method in this case.

CVS documentation

Basic CVS commands

A list of basic CVS commands is described here

CVS manual

The complete manual is available from ximbiot.com

Instructions for LHCb librarians

Instructions for LHCb CVS librarians are available here

-- MarcoClemencic - 15-Dec-2009

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback