Skip to main content
Jump to: navigation, search

Difference between pages "JDT Core Committer FAQ" and "Migration to SVN"

(Difference between pages)
(What target milestone should be used ?)
 
 
Line 1: Line 1:
== Meta FAQ ==
+
= Introduction =
 +
''' Work in Progress'''
  
=== Who is this FAQ for ? ===
+
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 FAQ is for the JDT/Core committers, and anyone who is willing to participate in the development of JDT/Core.
+
  
=== What is this FAQ about ? ===
+
== Why Migrate ==
This FAQ is about the rules that JDT/Core committers follow when developing the JDT/Core component.
+
  
=== How do I contribute to this FAQ ? ===
+
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
Simply edit this page. You will need to [http://bugs.eclipse.org/bugs/index.cgi?GoAheadAndLogIn=1 log in] using your bugzilla username and password to gain access.  If you don't have a Bugzilla account, you can [http://bugs.eclipse.org/bugs/createaccount.cgi create a new one].
+
  
== Coding ==
+
[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"]
  
=== Where is the JDT/Core code ? ===
+
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.
All the JDT/Core code is in the Eclipse CVS repository. The JDT/Core projects are:
+
* org.eclipse.jdt.compiler.tool
+
* org.eclipse.jdt.compiler.tool.tests
+
* org.eclipse.jdt.core
+
* org.eclipse.jdt.core.tests.builder
+
* org.eclipse.jdt.core.tests.compiler
+
* org.eclipse.jdt.core.tests.model
+
* org.eclipse.jdt.core.tests.performance
+
  
=== How do I create a CVS repository connection ? ===
 
The following information must be used to create a CVS repository connection:
 
* Connection type: extssh (or pserver if you are not yet a committer and don't have an Eclipse account)
 
* User: <your id> (or anonymous if you are not yet a committer and don't have an Eclipse account)
 
* Password: <your password>
 
* Host: dev.eclipse.org
 
* Repository path: /cvsroot/eclipse
 
* Use default port
 
  
=== What branch should I use ? ===
 
* HEAD: used for the development of the upcoming release. For example, HEAD is currently used for the development of 3.4.
 
* R3_x_maintenance: used for the maintenance of a release. For example, R3_3_maintenance is currently used for the development of 3.3.1.
 
  
== Committing to CVS ==
+
== Impact on STP Developers ==
  
=== How do I maintain the build notes ? ===
+
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 build notes (in org.eclipse.jdt.core/buildnotes_jdt-core.html) should be updated just before committing a bug fix. This file should be
+
committed at the same time as the bug fix. To update the build notes, use the JDT/Core tool (right click on the file, then JDT Core tools > Add to build note...).  
+
  
=== What comment should I associate with a commit ? ===
+
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.
The comment of a commit should be of the form: <branch> - <bug number with optional comments>, e.g.
+
* HEAD - 1234567
+
* R3_3_maintenance - fix for 123678 (with tests)
+
  
== Bugzilla ==
+
== Impact on components dependent on STP source ==
  
=== What bugs are currently opened against JDT/Core? ===
+
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.
[https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&classification=Eclipse&product=JDT&component=Core&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&resolution=LATER&resolution=REMIND&resolution=---&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Bugs opened and not resolved yet.]
+
  
=== What target milestone should be used ? ===
+
== Impact on the build system ==
# If the bug is marked as WORKSFORME
+
#: a) if you tested the problem with a pure milestone build, use this milestone (e.g. if you've tested that a problem works with a pure 3.4M1 build, then use 3.4M1)
+
#: b) if you tested the problem with an integration build, use the next milestone (e.g. if you've tested that a problem works with an integration build after 3.4M1, then use 3.4M2)
+
# If the bug is marked as DUPLICATE,
+
#: a) if the original bug has not been fixed yet, don't set the milestone on the duplicate (it will be set when rule 6 is applied)
+
#: b) if the original bug has been fixed, use either rule 1a. or rule 1b.
+
#: c) if the original bug has been set to WONTFIX or INVALID, use next milestone (rule 3).
+
# If the bug is marked WONTFIX or INVALID, use the next milestone (in this case, the target is simply used to identify that the bug has been closed during this specific period...)
+
# If the bug is marked FIXED, use the next milestone (as we always do)
+
# If a bug is backported to a maintenance stream, change the target milestone to the next maintenance release (e.g. if a bug fixed in 3.4M1 is backported to R3_3_maintenance, then change the milestone to 3.3.1)
+
# In all cases, go through the duplicates of the bug being resolved, and set these duplicates with the same milestone as the one used for the bug being resolved
+
  
=== What comment should be used when fixing a bug ? ===
+
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.  
When changing a bug to RESOLVED/FIXED a comment containing the following string should be use: "released for <target milestone | maintenance release>". E.g.
+
* Fixed and released for 3.4M2 in HEAD
+
* Released for 3.3.1
+
This string is used when querying the bugs to verify for a particular milestone.
+
  
=== The resolution LATER is deprecated. What should I use instead ? ===
+
== Impact on the directory structure ==
Bugs that we don't plan to fix used to be resolved as LATER. Since this resolution is deprecated, we shall now use the P5 priority.
+
  
=== The resolution REMIND is deprecated. What should I use instead?  ===
+
The directory structure will largely be unaffected by this migration. When we got to SVN, the repository structure will look something like:
Bugs that needed more information used to be resolved as REMIND. Since this resolution is deprecated, we shall now use the needinfo keyword.
+
  
=== What status/resolution should I use after marking a bug duplicate? ===
+
* branches
* If the original bug is marked RESOLVED/FIXED, leave it to RESOLVED/DUPLICATE
+
* tags
* If the original bug is marled VERIFIED/FIXED, change it to VERIFIED/DUPLICATE
+
* 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
  
== Release engineering ==
+
The directory structure under each of these will be identical to how it is currently structured in the CVS repository.
  
=== What steps should I follow to make a build contribution ? ===
+
Additionally we may have the following components (names subject to change)
# Ensure that you are in sync with the stream (HEAD, R3_x_maintenance, ...) you want to contribute to.
+
*      org.eclipse.stp.hybridmodel
# Close the build notes using the JDT/Core tool (right click on the file, then JDT Core tools > Close build notes).
+
*      org.eclipse.stp.scaeditor
# Commit the build notes.
+
*      org.eclipse.stp.eipatterns
# Tag all JDT/Core projects (even those that haven't changed) with the current version (found in the build notes), eg. v_810
+
*      org.eclipse.stp.soapolicy
# If needed, check out org.eclipse.releng from the stream you want to contribute to.
+
# Edit org.eclipse.releng/maps/jdtcore.map:
+
## Change the contribution date
+
## Change all version numbers to the new one
+
# Commit org.eclipse.releng/maps/jdtcore.map
+
# Send a message to the jdt-core-dev mailing list saying that the contribution was made including the version number, e.g. a message with the following title: "Released v_810 for today's integration build" and no body is sufficient.
+
 
+
== Misc ==
+
 
+
=== How do I get the JDT/Core tools ? ===
+
The JDT/Core tool can be obtained from this update site: http://www.eclipse.org/jdt/core/tools/jdtcoretools/update-site/ using Eclipse update manager.
+
 
+
=== An integration or maintenance build is red. Should I take it ? ===
+
A red build doesn't mean that it is not usable. It just means that some tests failed. The impact of failing tests is often negligeable. E.g. if the releng tests are failing, it just means that there is a problem in the Javadoc. So you should always take the latest integration or maintenance build, unless someone posted on the platform-releng-dev mailing list that it is not usable.
+
 
+
==Links==
+
*[[JDT Core| JDT Core Wiki Page]]
+
*[http://www.eclipse.org/jdt/core/index.php JDT/Core Home Page]
+
 
+
[[Category:FAQ]]
+
[[Category:JDT]]
+

Revision as of 05:13, 18 September 2007

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

Back to the top