Community
Participate
Working Groups
AFAIK org.eclipse.releng.tools hasn't been migrated to git. I'm still using the CVS repo and I can't find it here: http://git.eclipse.org/c/. Am I missing something? Kim, any plans regarding org.eclipse.releng.tools ?
They will be migrated along with the rest of the releng specific projects. I have to do some testing first before I can run the migration.
The migration of the releng features will occur starting tonight. The projects it includes are kmoir@build:~/migrationtestreleng/cvsroot/eclipse.platform.releng/bundles> ls org.eclipse.ant.optional.junit org.eclipse.perfmsr.feature org.eclipse.releng.tests org.eclipse.test.performance.data org.eclipse.cvs org.eclipse.perfmsr.releng org.eclipse.releng.tools org.eclipse.test.performance.win32 org.eclipse.pde.tools.versioning org.eclipse.perfmsr.startup org.eclipse.sdk.examples org.junit_3.8.2.v200705141327 org.eclipse.perfmsr.adaptor org.eclipse.perfmsr.ui org.eclipse.sdk.tests org.junit.source_3.8.2.v200705141327 org.eclipse.perfmsr.core org.eclipse.perfmsr.ui.client org.eclipse.test org.eclipse.perfmsr.core.java5 org.eclipse.rcp org.eclipse.test.dispatcher org.eclipse.perfmsr.core.win32 org.eclipse.rcp.platform org.eclipse.test.performance kmoir@build:~/migrationtestreleng/cvsroot/eclipse.platform.releng/features> ls com.ibm.icu.base master-jetty org.eclipse.license org.eclipse.releng.tools equinox master-root org.eclipse.pde.api.tools.ee.fragments org.eclipse.sdk master org.eclipse.cvs-feature org.eclipse.pde-feature org.eclipse.sdk.examples-feature master-ecf org.eclipse.equinox org.eclipse.pde.junit.runtime.addon org.eclipse.sdk.tests master-equinox org.eclipse.equinox.p2.user.ui org.eclipse.pde.junit.runtime.standalone org.eclipse.test-feature master-equinox-p2 org.eclipse.equinox.sdk org.eclipse.pde.p2-feature master-equinox-weaving org.eclipse.help-feature org.eclipse.platform-feature master-feature org.eclipse.jdt-feature org.eclipse.rcp Note: Some of these are old projects that have been moved elsewhere but I'm migrating them to preserve the history.
John, I noticed a problem with the repo. The platform feature used to be in /cvsroot/eclipse However, for 4.2 builds, it was moved to org.eclipse.sdk-feature/features/org.eclipse.platform-feature In the new repo, we'll have to have a separate location for it because we can't write the same project from different streams to the same location and preseve the history. I'm organizing the eclipse.platform.releng feature into directories bundles/ features/
We could do something similar to what was done for ui.workbench that had the 3.x and 4.x fork. 1) Convert your projects/features in 3.x in your final locations. 2) Create a different repo with the 4.x features in the exact same locations, 3) when you've got your main repo, you add the secondary repo as a remote and then fetch their master. 4) then you do a merge from secondary/master into whatever your target branch is, and use the command line to pick the entire project from one branch or another. PW
I talked to Kim about this offline. There's no big value in merging the histories of the two separate platform features together in a single folder. Their history isn't particular interesting anyway, except for the purpose of reproducing builds. So I think we'll leave them as separate directories, and soon the 3.x one will just become irrelevant (features rarely change in old streams).
If the history is not that important, why don't we convert the 3.x one. Then in the 4.x branch, simply deposit and commit R4_0, R4_1, and current ... then we can just keep going from there? PW
(In reply to comment #6) > If the history is not that important, why don't we convert the 3.x one. > > Then in the 4.x branch, simply deposit and commit R4_0, R4_1, and current ... > then we can just keep going from there? On further reflection, I'm not sure this is simple. One project would end up with R4_HEAD and the other would not. That would imply that adding the other project would mean hacking the CVS to contain the correctly dated and tagged changes, so that when they're converted to git commits they line up ... that sounds complicated :-) But if we don't have something useful there we can't recreate the 4.0 or 4.1 builds (by updating their builders to git), and these are arguably release builds. Do we put them in a different location to maintain the 4.x history, and after the git conversion dump the R4_HEAD of the platform-feature into its long term location and keep using that going forward? PW
Repo is here ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.releng.git I'm going to start a test build.
Test build was sucesssful. I've updated the maps in the master and R3_7_maintenance stream of org.eclipse.releng. John/Paul could you update the e4 maps at your convenience. I don't have e4 commit rights.
