Community
Participate
Working Groups
This is a plan item bug for the migration of the Eclipse and Equinox project's CVS repositories to git in the Juno timeframe. As John remarked in the Eclipse Planning call this morning, it would make sense to migrate to git early in the Juno release schedule and continue Indigo SR development in CVS. I'm not sure which bucket this bug belongs in since it's an item that belongs to the entire team, but it can start in the releng bucket.
Sweet, nice way to set the example.
In the past, the Eclipse SDK has included everything needed to build the SDK. If the Platform is moving to git, should egit move to the platform?
(In reply to comment #2) > In the past, the Eclipse SDK has included everything needed to build the SDK. > If the Platform is moving to git, should egit move to the platform? > That's a good question. In principle, I would be in favour of this, if all parties were interested and we could make the logistics work.
Related to that, we should also consider removing CVS from the Eclipse SDK after we migrate, at least in the 4.x stream. It could be a separate download in our repository for those who need it.
regarding comment #4 It's already a separate download so this would just be a matter of removing the CVS feature from the SDK.
I don't want to change the scope of this bug, but it seems that while moving our SCM, it might be an ideal time to revisit the platforms build process too (since it will have to change to some degree). Yesterday on the equinox/p2 call, we discussed what would be involved in building p2 separately and contributing our bits to the platform (this was just some initial brainstorming, nothing has been decided). However, if all the platform components (PDE, JDT, etc...) did this, then the platform build would really be a mini-EPP assembly process + integration tests. This would likely reduce build time and help maintain better separation between our components. This may also help components build / ship separately (as is the case with the Java 7 work in the JDT). The reason I bring this up here is because it's not clear (to me) if: 1. This is desirable 2. Assuming it is, would it be easier to do this as part of the migration to git? As I mentioned, I don't want to change the scope of this bug, but I would like to offer my help with this (especially on the p2 side of things). If this is something that should be integrated with the migration to git, then we can discuss it on the (separate) relevant bug reports.
Ian, Pascal has opened bug 345443 and bug 345445 for the issues wrt splitting p2 build out of the SDK build. I think this should be pursued as a separate issue. I would like to first transition to git and then investigate making the build more modular as I think this issue will take more work, esp. wrt running the tests and consolidating the results. I welcome your help :-)
(In reply to comment #7) > Ian, Pascal has opened bug 345443 and bug 345445 for the issues wrt splitting > p2 build out of the SDK build. I think this should be pursued as a separate > issue. I would like to first transition to git and then investigate making the > build more modular as I think this issue will take more work, esp. wrt running > the tests and consolidating the results. I welcome your help :-) Part of helping make the build more modular is also looking at breaking up your current CVS repository into more modular and independent git repositories. There are probably some perfect breaking points already: org.eclipse.jdt.git org.eclipse.pde.git org.eclipse.core.git etc These each would then have their own build and could be built independently. If each created a P2 repository with it's artifacts, these then could be consumed by the downstream builds that depend on them. Migrating to git is more than just migrating to CVS, it also is an opportunity to optimize the repositories for git itself.
(In reply to comment #2) > In the past, the Eclipse SDK has included everything needed to build the SDK. > If the Platform is moving to git, should egit move to the platform? EGit is already moving to Mylyn Builds, can't the platform SDK just consume the EGit p2 artifacts from there. It doesn't have to be housed in the eclipse platform itself.
Dave, regarding comment #8 the granularity of the Eclipse/Equinox git repos is being discussed in bug 345471. This (current) bug is a plan item bug so much of the discussion and work are taking place in the dependent bugs above :-)
(In reply to comment #2 and comment #4) If the SDK source is in a Git repo then Git should be part of the SDK and CVS has to go away. Personally I would prefer to wait one release with the removal i.e. ship both with 3.8/4.2 and then remove CVS in 3.9/4.3. This will give adopters enough time to react.
We had a meeting regarding the migration yesterday, John wrote some notes here http://wiki.eclipse.org/Platform-releng/Juno_Git_Migration
For removing binaries the easiest thing to do is to remove the corresponding ,v's before doing the import of your scratch copy of the CVS repo. There are downsides to this though: any tags and branches which included those binaries won't any longer. This may affect any builds which attempt to build an older tag from git in the future. If you'll always build old tags from CVS then I guess this is OK. It's also possible to remove the binary content after the fact using git filter-branch, but I suspect setting up the CVS repo as you want it to look before the import is the easiest way. > We need to maintain a CVS repository for performing builds on older branches (3.6.2+, 3.5.2+, etc). > Until we have a solution for this, we will need to keep our CVS repository writeable after the Git > migration. We can delete all content from HEAD in CVS to avoid confusion. I don't see why you'd want to do this. If it's planned to make releases from the older branches - and you plan to do this long term - surely it makes sense to fix up the map files and the releng plugins on the branches? Once the git releng has been sorted for HEAD, is it much work to get it going on the branches for the previous 3 major releases?
Thanks for the advice regarding binaries. Regarding comment #13, James it's really more like seven previous releases. The issue is the git fetch factory for pde build would have to be backported, build scripts modified and map files update for all those releases so we could fetch via git. And for those who may say why don't you switch your build system to one that supports git natively at the same time you're changing SCMs - we don't have the resources to do that right now, and none meet all our requirements (for instance, some don't allow us to compile against the seven BREEs we build with :-) The goal is to switch to git this summer which is a considerable amount of work in itself.
Just a note on maven and supporting/compiling with multiple different JDK's. It can be done, the tycho-osgi-compiler plugin would need to be updated to support the settings that the maven-compiler-plugin already support. http://unserializableone.blogspot.com/2008/09/compile-and-test-with-different-jdk.html Anyways, I'd suggest opening an enhancement request with the Tycho folks if it is something that you really need to have. I know that Tycho will down compile to a specific BREE.
What's the plan for the secondary CVS repositories associated with projects? E.g. the webpages are currently on /cvsroot/org.eclipse/ , and some of the pages also contain binaries like developer tools that are not officially shipped e.g. http://eclipse.org/eclipse/platform-core/downloads.php or http://eclipse.org/jdt/ui/astview/index.php . In JDT UI, we reused the old /cvsroot/eclipse/jdt-ui-home/ to host the sources of these tools, so we would also need a new home for these. Will the web pages stay on CVS for now?
(In reply to comment #16) > What's the plan for the secondary CVS repositories associated with projects? This is covered by bug 324116. I thought the Eclipse Foundation was going to take care of this migration, but I have asked for clarification on the bug. > In JDT UI, we reused the old /cvsroot/eclipse/jdt-ui-home/ to host the sources > of these tools, so we would also need a new home for these. I would think you should include those sources in the same repository as your tests and other code, possibly under a different folder if you want to keep them separate.
(In reply to comment #17) > (In reply to comment #16) > > What's the plan for the secondary CVS repositories associated with projects? > > This is covered by bug 324116. I thought the Eclipse Foundation was going to > take care of this migration, but I have asked for clarification on the bug. > > > In JDT UI, we reused the old /cvsroot/eclipse/jdt-ui-home/ to host the sources > > of these tools, so we would also need a new home for these. > > I would think you should include those sources in the same repository as your > tests and other code, possibly under a different folder if you want to keep > them separate. Or if they are completely seperate, host them in their own git repository. It all depends on how often things are needed and accessed.
I have raised bug 359466 to request removal of the CVS from the Eclipse SDK and to be made available as a standalone feature
I'm going to close this bug. There are a few remaining issues open but our entire code base has now been migrated to Git. The two builder projects are still in CVS but we're going to defer migrating these for now to focus on bug 355430, which is making the 4.2 stream build the primary build.
> our entire code base has now been migrated to Git. Congratulations! The work done here is nothing short of impressive.
Has git.eclipse.org/gitroot/platform/eclipse.platform.releng.git been migrated? If so, please update http://wiki.eclipse.org/Platform-releng/Git_Workflows and http://wiki.eclipse.org/Platform_UI/Git.
(In reply to comment #22) > Has git.eclipse.org/gitroot/platform/eclipse.platform.releng.git been migrated? Yes: http://git.eclipse.org/c/platform/eclipse.platform.releng.git/ > If so, please update http://wiki.eclipse.org/Platform-releng/Git_Workflows and > http://wiki.eclipse.org/Platform_UI/Git. Done.
