Migration to SVN

Introduction

This page outlines a proposal to migrate the STP code from its current CVS repository over to a Subversion (SVN) repository. We'll first look at the reasons why this is being considered. Following this will be an outline of the impact on components using STP source, the build system, and finally a proposal as to how the directory structure will appear in the new repository.

Why Migrate?

There are pro's and con's with either version control system, this wiki page wont spend too long discussing the topic. A number of references are included below

• "Interesting Devx article comparing CVS and SVN"
• "Redhat.com article on CVS SVN"
• "Online SVN Handbook"

From experience gained with both CVS and SVN, SVN's ability to version control directories & better management of branches / tags / copying resources it is a much better system to work with. The migration to SVN is fairly straightforward for CVS developers as most of the concepts and commands are the same.

Impact on STP Developers

The migration will need to be carefully planned. All developers with checkouts will need to commit prior to migration over to SVN, otherwise they will manually need to get their changes onto the SVN repository. All history, tags etc. will be preserved so we wont lose any of the data with each file. Once the migration is complete, details of repository connection details will be provided on the STP Developer pages and all subsequent checkouts will need to use the Subversion repository. As part of the migration we will provide documentation on the structure of the repository and how to go about code development.

All developers will need to have an SVN client installed into their development eclipse environment in order to be able to do checkouts / commits directly from the IDE.

Impact on components dependent on STP source

Any project that uses STP source code as a basis for their tooling development will be impacted by this change. If they rely on published builds this will not impact them. If you take in the source code from CVS, mail the STP developers alias and we'll work with you to get your processes updated for the new repository.

Any organizations that are using continuous build process will need to be updated (e.g. Cruisecontrol will need to migrate it's bootstrappers from CVS to SVN).

Impact on the build system

The build system will be heavily impacted by this migration. The basis of our build system is documented at STP_Build_101 but the key highlight here is the dependency of the map files to go to a CVS repository and checkout the version of the code that is required to be built. All these map files will need to be updated to point to the location of the new SVN repository. However, once the checkout operation is done, the rest of the work of the build system is largely unaffected. The download page and the process of syncing over the built content to it will remain unchanged.

Impact on the directory structure

The directory structure will largely be unaffected by this migration. When we got to SVN, the repository structure will look something like:

* branches
* tags
* trunk
*       build
*       org.eclipse.stp.b2j
*       org.eclipse.stp.bpmn
*       org.eclipse.stp.contrib
*       org.eclipse.stp.core
*       org.eclipse.stp.servicecreation
*       org.eclipse.stp.soas

The directory structure under each of these will be identical to how it is currently structured in the CVS repository.

Additionally we may have the following components (subject to approval by PMC, names subject to change)

*      org.eclipse.stp.eipatterns
*      org.eclipse.stp.hybridmodel
*      org.eclipse.stp.scaeditor
*      org.eclipse.stp.soapolicy
*      sandbox

All work towards the eclipse 3.4 release will be done on trunk. No branches are planned initially, but should they be required they will be created.