Difference between pages "Migration to Git" and "Rodin Platform Releases"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Laurent
m (→‎Writing Rules: Add link to rules file)
 
imported>Pascal
 
Line 1: Line 1:
 
{{TOCright}}
 
{{TOCright}}
  
The source files of the Rodin platform and associated plug-ins are under
+
== Release Policy ==
version control on SourceForge. Initially, we used CVS and we migrated to
+
* The Rodin platform is released every 3 months.
Subversion in March 2009. This page describes the migration to another
+
* The code is frozen during the 2 weeks preceding each release.
version control system: Git.
+
* Each release is announced on the [[Mailing_lists | Devel]] mailing list. Two days later, the information is broadcast on the [[Mailing_lists | Announce]] and [[Mailing_lists | User]] mailing lists.
 +
* The [http://wiki.eclipse.org/index.php/Version_Numbering Eclipse versioning policy] is enforced.
 +
* The optional plug-ins shall strive to meet the release date: the release will not be held back.
 +
* The news related to the optional plug-ins are spread on the [[Mailing_lists | Announce]] and [[Mailing_lists | User]] mailing lists.
 +
* A wiki page is dedicated to each release. Select a version from the lists below to see the corresponding release notes.
  
The migration from CVS to Subversion was far from perfect.  But then, there
+
== Upcoming Releases ==
was not much time available for polishing it. In this new migration to Git,
 
we would like to start again from scratch and first migrate the CVS repository
 
to Git, then all the subsequent commits in Subversion.
 
  
Another concern is that the Subversion repository has grown very large.  We
+
{{SimpleHeader}}
would like to split it in several smaller repositories, which is now possible
+
|-
with Git. The new repositories should each correspond to a set of plug-ins
+
! scope=col | Version || Scheduled Release Date
which are delivered together.
+
|-
 +
|[[Rodin Platform 1.3 Release Notes|1.3]] || 30/04/2010?
 +
|-
 +
|[[Rodin Platform 2.0 Release Notes|2.0]] || 30/07/2010?
 +
|}
  
<strong>Important Note:</strong> Make sure that all conversions are performed in a case sensitive filesystem. For instance, on Mac OS X, create a special Volume with a different filesystem than the default (which is case insensitive).
+
== Previous Releases ==
  
==Migration of the SMT plug-in==
+
{{SimpleHeader}}
 +
|-
 +
! scope=col | Version || Release Date
 +
|-
 +
|[https://sourceforge.net/projects/rodin-b-sharp/files/Core_%20Rodin%20Platform/1.0/ 1.0] || 01/07/2009
 +
|-
 +
|[[Rodin Platform 1.1 Release Notes|1.1]] || 15/10/2009
 +
|}
  
To begin the migration to Git, I started with a very simple set of plug-ins: the SMT Solver plug-ins. Their history is linear, with just some renaming from time to time. All the development was performed in Subversion.  The conversion was performed with <tt>git-svn</tt> with no special constraint using [https://sourceforge.net/p/rodin-b-sharp/rodincore/ci/master/tree/org.rodinp.releng/gitMigration/migrate-svn-smt.sh migrate-svn-smt.sh].
+
[[Category:Rodin Platform Release Notes]]
 
 
==Migration of the Core Platform==
 
 
 
For the Core Platform, the migration is more intricate.  As stated in the introduction, the initial conversion from CVS to Subversion was of average quality. Moreover, when one includes the sources in the <tt>_exploratory</tt> directory, the files to migrate are a bit scattered all over the place.
 
 
 
The migration is then performed in three steps:
 
- Migrate the CVS repository
 
- Migrate the Subversion repository
 
- Merge the two together
 
 
 
===From CVS===
 
 
 
This is done with the ZSH script [https://sourceforge.net/p/rodin-b-sharp/rodincore/ci/master/tree/org.rodinp.releng/gitMigration/migrate-core-from-cvs.sh migrate-core-from-cvs.sh].  This script
 
creates a fresh Git repository from a CVS archive (67 MB). To run it, one
 
needs the CVS archive be named <tt>cvs-Rodin-b-sharp.tgz</tt> and
 
an author-mapping file named [https://sourceforge.net/p/rodin-b-sharp/rodincore/ci/master/tree/org.rodinp.releng/gitMigration/Authors.txt Authors.txt].
 
 
 
After running the script, the git repository needs some massaging:
 
* Fix three commit messages that are not UTF-8:
 
      939bacf56436084c5fb58b041a26c9fe4dd7d876 (2008-01-16T18:57:44Z)
 
      d2eca7a9ec561c2c7bfbc9c5d57ca9558964ee87 (2008-10-02T16:46:07Z)
 
      dccf0b77d7d20538a44df5aac719646eb2b62fa4 (2008-10-09T13:06:44Z)
 
* Merge the branch UNDO_DEV back into <tt>master</tt> as described below.
 
* Rename tags into a hierarchy.
 
 
 
====Merging a Branch Back in Main Branch====
 
 
 
After importation from CVS, some development branches are dangling.  To make history easier to browse, one needs to merge them back into the main development branch. This is done by grafting.
 
 
 
Suppose that the development branch <tt>mybranch</tt> needs to be merged back into the main development. First, identify the commit where the branch has ceased to be useful. Let's name this commit <tt>mergepoint</tt>. Then, type:
 
      echo $(git log -1 --format=format:'%H %P' mergepoint) \
 
            $(git show-ref -s branch) >> .git/info/grafts
 
 
 
Then check that this change works fine and type the following command to make it permanent:
 
      git filter-branch -- --all
 
 
 
The branch names can now be removed with
 
      git branch -d branch
 
      git branch -d mergepoint
 
 
 
====Renaming Tags into a Hierarchy====
 
 
 
After importation from CVS, the tags were named:
 
I20060720
 
 
fr.systerel.explorer-0.0.1
 
fr.systerel.explorer-1.0.0
 
org.eventb.core-0.5.1
 
org.eventb.core-0.5.3
 
 
 
This is a long list and it is not very practical. However, Git supports hierarchical tags, like a filesystem. To benefit from this, type the following commands:
 
cd .git/refs/tags
 
mkdir RodinCore
 
mv I* RodinCore/
 
ls | grep -e '-' | cut -d- -f1 | sort -u |
 
    for f in $(cat /tmp/a); do
 
        mkdir $f
 
        for g in ${f}-*; do
 
            mv $g $f/$(echo $g | sed "s:^${f}-::")
 
        done
 
    done
 
 
 
The list of tags becomes much shorter, as they are now neatly organized by plug-ins.
 
 
 
===From Subversion===
 
 
 
The Subversion commit that corresponds to the last commit done in CVS is <tt>r6896</tt>.  However, the first interesting Subversion commit is <tt>r6903</tt>.  In between, lie some Subversion commits for massaging the result of porting from CVS, which can be ignored.
 
 
 
====Extracting All Paths====
 
 
 
The first task is to identify the interesting paths in the Subversion repository, that is the ones to extract to the new Git repository.  For this, I have installed the tool [git://git.goodpoint.de/svneverever.git svneverever] and run it like that (assuming that I have a full copy of the Subversion repository from SourceForge in <tt>/tmp/svn</tt>):
 
    svneverever --tags --branches --no-dots file:///tmp/svn > svn-paths.txt
 
 
 
The resulting file contains all the directory that have ever been committed to the Subversion repository.
 
 
 
====Writing Rules====
 
 
 
From the contents of the previous file, I have written rules for [git://gitorious.org/svn2git/svn2git.git svn2git from KDE]. They are available in file [https://sourceforge.net/p/rodin-b-sharp/rodincore/ci/master/tree/org.rodinp.releng/gitMigration/RodinCore.rules RodinCore.rules].
 
 
 
 
 
 
 
[[Category:Developer documentation]]
 
 
[[Category:Rodin Platform]]
 
[[Category:Rodin Platform]]
 +
[[Category:Release Notes]]

Revision as of 16:53, 5 February 2010

Release Policy

  • The Rodin platform is released every 3 months.
  • The code is frozen during the 2 weeks preceding each release.
  • Each release is announced on the Devel mailing list. Two days later, the information is broadcast on the Announce and User mailing lists.
  • The Eclipse versioning policy is enforced.
  • The optional plug-ins shall strive to meet the release date: the release will not be held back.
  • The news related to the optional plug-ins are spread on the Announce and User mailing lists.
  • A wiki page is dedicated to each release. Select a version from the lists below to see the corresponding release notes.

Upcoming Releases

Version Scheduled Release Date
1.3 30/04/2010?
2.0 30/07/2010?

Previous Releases

Version Release Date
1.0 01/07/2009
1.1 15/10/2009