Home » Groups » STAR Protected

git in STAR

Updated on Tue, 2012-11-06 15:40. Originally created by jeromel on 2012-09-06 09:07.

 
Possible implementation of git in STAR

Rationals

STAR has been using CVS as its code versioning system for years but, while CVS is accessible over AFS and hence ot major sites, CVS does not provide several features modern versioning control systems do provide. Considerations for a new system however implies multiple criterion and requirements as desribed below.

Requirements

For STAR needs, a new system should support the following possibilities:

  • A system should allow all STAR users to access the repository as read

  • A system should allow grouping of users to access specific branches or sub-branches (for example, user A,B,C access all of StRoot/ while users D,E,F may access StRoot/StEvent)

  • The system should allow Web service or service access of the repository (i.e. No AFS mechanism imposed) – however, the system should respect an authentication method consistent with BNL policies (for example, users with no valid RCF account should not be allowed to have write access to our repository)

  • CVS does not have public (beyond STAR) and private areas – a new system may introduce the possibility to have widely public code repositories (community work)

  • Code repository should be browsable and searchable from a Web interface (cvsweb like). Features would minimally include code difference

  • Code commit to a central repository MUST be encouraged (central code availability is enforced by STAR rules and a new system should not allow violating its principles)

    • NB 1: the spread of secondary repository would not work for STAR as code divergence could create instabilities we did fight against for years. Examples have been disastrous side effects of embedding code divergence between BNL and the RCF, user code lack of synchronization amongst analysis teams (leading to non-reproducible results)

    • NB 2: STAR publication pilicy REQUIRES for code to be available to all users

  • However, and since we have observed entire copies of branches (CVS system) of codes from StRoot/ to offline/users/xxx, we would like for the new system to allow maintaining in the same central repository, parallel branch versioning user may work from and available for later re-merging with the main branch and core development

  • A new system should be accompanied by help and documentation in diverse form to ease user migration from one system to another

  • Note: the ideal situation would actually wrap the cvs common commands and translate them behind the scene, displaying information to users on what the new command would be. If this is not possible, a “XXX for CVS users” should be provided

  • A new system should provide ways to convert STAR repositories into the new system AND preserve access grants and rights to branches

  • A new system should have features such as Email notification upon code modifications (a-la-CVS)

 

Choice of solution, discussions and notes

git was proposed and evaluated to satsify the above requirements. Several questions were raised

  • CVS import to git automatic? Let's start from that.

  • Study CVS access rules / how to import (karma)

  • CVS notifications - how to do this? Does git allows this?

  • CVS Web browsing cvsweb.cgi equivalent?

  • Documentation, help, command wrapper around cvs commands to facilitate transition. Does this exist by any chances?

  • Study how to set a repository through a Web service / general http access

  • git is too easy to use for "cloning" - how do we ensure code is back to a central repository and control the spread of secondary repositories?

 

A few links and pointers

provided to answer some of those questions

Notes from Martin Girard and Piotr Ostrowski, 2012/04/05

We could import as example StHbtMaker and StMuDSTMaker from CVS to Git, but using cvs2git rather than git-cvsimport. It could be done without any problems. The way to do it is well explained here http://cvs2svn.tigris.org/cvs2git.html .

Then we make a super project putting StHbtMaker and StMuDSTMaker as submodule. You can then clone the whole project or just part of it. Some more explanations about submodule can be found here http://book.git-scm.com/5_submodules.html .

Right now I am checking the possibility to send notifications. It's done through hooks and doesn't seem to be a problem, but we should decide when it has to be send. I guess when a push is done to the origin directory. You can find information about hooks here http://book.git-scm.com/5_git_hooks.html .

An example of small script here http://www.dmst.aueb.gr/dds/ismr/colab/git_logscript.htm

 

Notes from a discussion with Patrick Huck, 2012/11/06

A few things were discussed again as follows:

  • AAA: we can use gitlolike or gerrit system
    • The gerrit system seems best to suit our needs (i.e. code is centralized with local offshoots for convenience of work - see OASP for example) - this would provide ACL-like aAa)
    • For Aaa, we can think of investigating Kerberos/git (here or check the apache_mod_krb) - this for remote access to git://
  • We would deploy by wave and large chunk
    • This implies a test area (and final place where we can setup and play with it)
    • It will require a time during which conversions from CVS to GIT are needed daily
    • We would then put in place GIT trees (entire StRoot/ for example) and ask users to check and play with it, then schedule a date at which the GIT path is the main repository and no longer the CVS one
    • Dependencies: For this to happen, we need
      • to be sure the full set of codes in CVS is transformable
      • a final new Web server/service with apache_mod_krb
  • The Huck will prepare a presentation for an S&C meeting to come before any move forward (make sure to gather feedback and relaunch the topic as the last time we advertized git as a possibility, was not too far off + students disappeared)

For now, we should focus on the conversion (local git repository is fine; suggested a soft start with StRoot/StEvent but ALL codes under StRoot/ as well as "kumacs pams StDb StarDb asps QtRoot StRoot StarVMC mgr QtRoot" will eventually need to be converted at some stage. Patrick could test a conversion script running daily taking care of all of those codes. Deployment to the final location would be easier if this ground work is done in advance.

When the Web server is ready, we would move his local testing ground and scripts to the final destination and start daily conversion and expand on testers.

TODO AS WELL: Patrick needs to review the requirements and ask questions to make sure the solutions envisioned fit the STAR (historical or hysterical) picture.

 

Groups: