Migration from CVS to GIT

IMPORTANT!!! by no means the statements written in this page are official. At the moment one should consider this information just and only for experimental purposes. There are no official decisions made by the OCT so far regarding migration to GIT or any other source control tool.  At the moment CVS is the official tool used and you can navigate the project history and code at our official code and history inspector Fisheye OpenACS

Tools to consider for the migration:

• GIT includes a tool for the migration of CVS repositories called git-cvsimport.
• The cvs2svn project provides support for converting a CVS repository into GIT. The tool is called cvs2git

Structure of the GIT Repository:

• One git repository hosting the entire code base of OpenACS (including contrib and all packages) vs. multiple repositories (provide separate git repositories managed via modules/subdirs/...)
• A single large repository seems not realistic, since many sites have site-speciifc modules, since there projects like ProjectOpen and others having developed a long range of maintained packages. But are 300+ separate repositories manageable with reasonable effort (maybe mr is currently the best option, we have good experiences with this). However, this decision has large impact on tagging and release management (see below)

Where could the repositories live (?):

• Official repositories on openacs.org machine? Having remote-mirrored repositories on github so developers can clone and share patches using github. -- jiml: many tools which could get similar function to github (forking, pull requests),,,  can we put up a gitorious on a test site with maybe 50gb of repo space so all the committers can have their own?
• Using github.com as our official source code site? or Bitbucket?

Points to consider before | when migrating to GIT: 

• Release-management: Installing-software-from-repository code is based on release "channels" and cvs-tags in order to define which channels are available to users ( https://openacs.org/repository/) and to provide the recent packages for that channel.  In principal, similar tags could be used as well in git, but there are several differences. CVS tags are per file, git tags are per repository (if the git repository contains e.g. all packages, there is no way to tag a single package as e.g. OpenACS 5.9 compatible with e.g. tag "openacs-5-9-compat"). It is possible to work with separate git repositories and work with git modules and/or subtrees, but this means that we have 300 repos to manage (all could have separate branches and tags), and single commits covering multiple repos are not supported). This means, that one needs higher level tools and recommended workflows to manage developments on the core source repositories (branches, tags) and site-specific packages and local modification as well as site-specific release and feature branches
• Depending on the decision of the structure it is necessary to provide git-guidelines similar to cvs-guidelines and the code retrieving and generating .apm packages has to be rewritten.
• Application for voting on oct-elections depends on commits history ( most likely this will transparent since we use fisheye.openacs.org  for fetching information about commit history, and fisheye provides one and one only interface for querying data, so the fact that the code is being controlled by cvs or git is irrelevant ... but since fisheye is configured for CVS, it has to be newly built for the resulting infrastructure, or it has to be dropped/replaced by github/bitbucket or others.

Current state:

• Since 2014 Victor Guerra (Vienna University of Economics) has created an unofficial mirror on github https://github.com/openacs which contains a daily mirror of the CVS repositories at openacs.org. It consists of an openacs-core modules plus a separate repository for every non-core package.