[Insight-developers] ITK CVS ->Git

[Brad King]

Hi Folks,

I'm nearly finished with the one-shot history conversion of ITK from
CVS to Git.  I'm preparing 3 repositories:

 - The main toolkit (currently "Insight" under cvsroot)
 - The applications (currently "InsightApplications" under cvsroot)
 - The data submodule (currently inside "Insight/Testing/Data" under cvs)

I chose to extract the Testing/Data directory as a Git submodule and
retroactively write the main toolkit's history to refer to it on matching
commits.  This reduces the main toolkit repository size by a lot, and
will help us move the test data out to a separate module later anyway.
We can still reproduce any old version of the tree because every main
toolkit commit refers to the exact version of the data that it needs.

I've done something similar to the old Unsupported, Auxiliary, Applications,
and Examples (back when it was applications) directories.  They refer
to the applications repository as a submodule for versions of the main
toolkit when they were in the main tree.  This allows the new applications
repository to share the full history of the applications even from before
they built as an outside project.  It also keeps the applications history
objects out of the main toolkit repository while still allowing us to
reproduce trees from back then.

There are a few decisions to be made:

-------------------------------------------------------------------------
(1) We need to freeze CVS repository commits so that I can convert the
last few changes (and the 3.20 branch) that have come in since I last
synced from the CVS server.  Unlike release freezes, *nobody* will have
commit access, and it will never un-freeze.  We need to select a schedule
of events for the final transition.

 (a) Freeze CVS
 (b) Final CVS->Git conversion
 (c) Enable Git repositories
 (d) Update web pages and add developer docs on the Wiki
 (e) Update all dashboard submission clients to fetch from Git

I can do steps (a), (b), and (c) during the course of two days or so
after the freeze.  I'll coordinate step (d) with Luis.  Step (e) will
need help from everyone maintaining a dashboard submission.

 (e.1) Install CMake 2.8.2 or later.  This is needed for its Git
 support in ctest_update().  It can work with 2.8.0 and 2.8.1 if
 we put some helper code in the dashboard scripts but it is much
 easier to use 2.8.2.  Fix cron jobs to run the dashboard script
 with the newer CTest.

 (e.2) Update the dashboard client scripts.  For VTK (and CMake)
 we now use a "vtk_common.cmake" ("cmake_common.cmake") dashboard
 script helper.  It contains the main dashboard client logic to
 keep machine-specific scripts small.  This is an opportunity to
 simplify all our scripts by creating "itk_common.cmake".

Step (e) will leave the dashboard in disarray for a while, so I propose
that even after (c) we do not publish any non-fix changes.

I propose to begin with step (a) tomorrow morning (Friday, July 23).
That way we can spend next week cleaning up dashboard clients.

-------------------------------------------------------------------------
(2) We need to choose the new URLs at which the ITK Git repositories
will appear.  Note that the part between the last '/' and '.git' will
serve as the default local directory name for "git clone".  However,
the data repo will generally not need to be cloned explicitly.  It will
be cloned inside the main source by the "git submodule" porcelain.

To preserve the same names we're using in CVS, the URLs would be:

  git://itk.org/Insight.git              (main)
  git://itk.org/InsightApplications.git  (apps)
  git://itk.org/InsightData.git          (data)

Alternatively we could take this opportunity to make the URLs
shorter (better for slides!):

  git://itk.org/ITK.git                  (main)
  git://itk.org/ITKApps.git              (apps)
  git://itk.org/ITKData.git              (data)

One other idea is to rename the main repository to match that
used for the release tarballs:

  git://itk.org/InsightToolkit.git       (main)

but this makes it even longer!

FYI, there will be "http://" equivalents of all the URLs to enable
clones through restrictive firewalls.

Comments?
-Brad