Current LHCb SVN Usage model, and common mistakes:

Herein is documented the typical actions of users of the LHCB SVN reopsitory which should be supported by core software. The first point of call for a new user should be the SVNUsageGuidelines.

Introduction, user types

There are four different types of SVN-users with different usage patterns:

  1. Users
  2. Developers
  3. Managers
  4. Librarians

  1. Users only check out, never in.
    • the entire world, mostly lhcb-general
    • don't know anything about svn, don't need to know anything, don't want to know anything
  2. Developers have mastery over the content of individual packages, and user-tags but not projects or production-tags
    • They regularly commit code, bugs and bugfixes, often make svn-mistakes which are mostly easy to correct.
    • lhcb-svn-writers
    • know very little about SVN, how to checkout/in and switch, little more, don't need to know any more
    • SVNUsageGuidelines
  3. Managers have mastery over a select number of projects and all tags/packages within those projects.
    • They irregularly commit new code, but regularly make bugfixes, less often make svn-mistakes, but make them in a way they are difficult to correct.
    • lhcb-release-managers
    • Experts on SVN, know how to do most things, but not the most complex operations, minor abilities in repairing the repository
    • PrepareProjectRelease
  4. Librarians never improve the codebase, they have mastery over the complete repository,
    • can move packages around at will, are responsible for the scripts and access permissions for the repository
    • super power users of SVN, know next-to-everything about it
    • they maintain the general health of the repository and respond to manager and developer questions
    • SubversionSupport

Often users can fall into more than one category...

Common repository actions:

Given in the workflow of a typical user in the development/release cycle.

- Releasing Perfectly in 24 hours (manager actions):

  • Check tag collector
  • Tag all required packages using tag_package or Tag collector
  • Create project tag
  • Prepare and tag new XXXSys with tagged packages
  • use cmpPackageWithTrunk to check everything is OK
  • Enter new package into Nightlies
  • Wait for tomorrow, all is good
  • Request release

Notice that this is the shortest possible number of steps. This is the procedure which should be followed, because it is the quickest.

Further instructions on PrepareProjectRelease

- Developing flawlessly (developer actions):

  • get in touch with the release manager in case the change is major or urgent
  • make a savannah entry if it is a bug, or a major change, or something affecting production
  • getpack the head of a package
  • make a small backward-forward-compatible improvement
  • commit to SVN
  • make an entry in the tag collector
  • watch the nightlies results that the change has been adopted
  • update the qmtest references and make another entry in the tag collector

Further instructions on SVNUsageGuidelines

- Developing off the beaten path (developer and manager actions):

  • Ask the release manager to make a branch
  • getpack that branch
  • perform the development
  • (maybe) make a user tag to share with collaborators or mark semi-stable versions
  • Development completed, inform the release manager that an official tag should be assigned
  • release manager does the tag, maybe it goes into the next release, or a patch release on a previous stack

- Misc actions:

  • Creating new packages/projects:
    • i.e. making directories in the repository, and in the tags directory. Developers should be able to do this.
  • Moving packages between projects:
    • A simple script is available, or the librarian can do it
    • The tags, branches, and trunk need to be moved at the same time. This is the equivalent of an svn-cp svn-rm, so somebody has to have the rights to rm the entire tags for a package

Common problems and solutions

I will now go through the most common problems and the quickest solutions. In most cases these are noticed after the nightlies have been run, so after all the official tagging has been made. When I say "retag" I mean: remove existing tag, edit release notes/requirements, tag again with the same tag

Ideally most of these problems would be avoided with smart svn-commit-hooks

A: Where can the release manager go wrong?

  1. Accidentally tagging the wrong thing with the wrong version
    • retag the right thing with the right version
  2. Forgetting to tag something
    • tag it, retag XXXSys
  3. Tagging something but forgetting to put it into XXXSys
    • retag XXXSys
  4. Totally screwing up the repository with a stupid command
    • look through SVN history to find when you did it, and restore the correct directory with an svn cp -r...
  5. Some of the nightly test references need updating
    • run the tests locally, retag the relevent packages

B: Where can the developer go wrong?

  1. Requesting a tag without committing the changes
    • maybe the release manager notices this, or the developer notices this
    • wait for developer commit and retag the package
  2. Not requesting a tag when changes have been made
    • Hopefully the release manager notices this
    • tag the package and retag XXXSys
  3. Requesting a tag when changes have been made but those aren't the latest changes
    • Hopefully the release manager notices this
    • wait for the developer response and retag accordingly, may require a branch
  4. Requesting a tag for the latest changes which aren't actually supposed to be there
    • remove the tag entirely
  5. Requesting a tag with the latest changes where some of them are supposed to be there, and some of them are not
    • branch and retag
  6. Causing a bug in the release candidate
    • wait for the developer fix OR retag without the change
    • retag package OR tag package and retag XXXSys
  7. Doing their development on a tag, instead of the trunk
    • restore previous tag content
    • wait for developer svn-switch
  8. Doing too much development all in one go, making the head incompatible with anything before
    • probably need a branch for previous-stack changes... see below
    • may need to restore a previous version of the trunk
  9. Tagging with a production tag
    • only the release manager should be able to make tags of the form vXrYpZ
    • moving this tag to a tag of the form user_YYYYMMDD is the quickest fix.

C: Things nobody but the librarian should ever do:

  • Remove a tag which was already released
  • Edit a tag
  • Add to or remove from an existing tag
  • remove the entire repository
  • remove an entire project
  • remove an entire package unless it is during a package migration
  • remove the tags/trunk/branches directory unless it is during a package migration


-- RobLambert - 18-Nov-2010

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2010-11-18 - RobLambert
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

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