Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between pages "JDT Core Committer FAQ" and "Migration to SVN"
(Difference between pages)
(→What target milestone should be used ?) |
|||
| Line 1: | Line 1: | ||
| − | == | + | = Introduction = |
| + | ''' Work in Progress''' | ||
| − | + | 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. | |
| − | This | + | |
| − | === | + | == 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 | |
| − | + | ||
| − | + | [http://www.devx.com/opensource/Article/27884 "Interesting Devx article comparing CVS and SVN"] | |
| + | [http://www.redhat.com/magazine/010aug05/features/subversion/ "Redhat.com article on CVS SVN"] | ||
| + | [http://svnbook.red-bean.com/ "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. | |
| − | The | + | |
| − | + | ||
| − | + | 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. | |
| − | + | ||
| − | === | + | == 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | === | + | == 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 (names subject to change) | |
| − | + | * org.eclipse.stp.hybridmodel | |
| − | + | * org.eclipse.stp.scaeditor | |
| − | + | * org.eclipse.stp.eipatterns | |
| − | + | * org.eclipse.stp.soapolicy | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 05:13, 18 September 2007
Contents
Introduction
Work in Progress
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.
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.
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 (names subject to change)
* org.eclipse.stp.hybridmodel * org.eclipse.stp.scaeditor * org.eclipse.stp.eipatterns * org.eclipse.stp.soapolicy