Bugzilla – Full Text Bug Listing
| Summary: | Migrate GEF CVS repository to Git | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Alexander Nyßen <nyssen> | ||||
| Component: | RelEng | Assignee: | Alexander Nyßen <nyssen> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ahunter.eclipse, irbull | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | 3.8.0 (Juno) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 363394, 367582, 371278 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Alexander Nyßen
Created attachment 201737 [details]
Patch converting org.eclipse.gef.releng gef.map file to Git format
Anthony, attached is a patch that converts the currently checked in gef.map file of our releng project into a GIT fetch format (pointing to the CVS git mirror already hosted at eclipse.org). While the map files contain fixed tags (which are probably exchanged by the common modeling build infrastructure?) we could nevertheless give it a try to see if we could migrate our repository without also having to replace our build process in the short term.
As I do not have the access rights to trigger a build myself, that part would unfortunately be up to you...
I would rather not try this, as this would immediately imply keeping the existing build tools on GIT when we have wanted to move to "something else" for several years. Ian, you going to do the new build or is that a no? Hi, Has GEF moved to Git yet? I can see Zest in Git, but not GEF or Draw2D. (In reply to comment #2) > I would rather not try this, as this would immediately imply keeping the > existing build tools on GIT when we have wanted to move to "something else" for > several years. > > Ian, you going to do the new build or is that a no? Anthony, from the personal communication I had with Ian here at EclipseCon, I infer we should not expect something to happen (Ian, please contradict me, if this is not the case). I have talked to Kim Moir here at EclipseCon as well w.r.t. to the migration issue, and she confirmed me in the fact that migrating the pde based platform should basically be done by changing the map file format (I am not sure what would have to be done w.r.t. build tagging, because I am not aware how this is currently done, but for the platform it seemed to have worked this way). As such I would recommend to try out what I have proposed so far and migrate the repo based on the old pde based build first. I have enough pde build experience to support you with that (but I do not have the access rights to try it out myself). As I have already performed the task of setting up a tycho based build for the new GEF4 geometry stuff I have created in the last months (see bug #355997 for details; actually I also got to work the api documentation generation there) I could offer to reinvestigate the "new build story" based on tycho after the migration. I do not think it makes sense to do both at a time. I have created bug #363394 to keep track of the need for a new Hudson/Tycho based build infrastructure. I will take responsibility of setting this up. I have requested access rights to first investigate the problems of the current build infrastructure w.r.t. the javadoc generation problems. In parallel, I will try to enrich the GEF4 Hudson/Tycho-based nightly build so that it makes use of all the features we will need for GEF proper as well (signing, source bundles, etc.), so that can be easily transferred. Based on the experiences I will gain with these two approaches, we can decide on what strategy will be the best suited for us (i.e. migrating the build system first, or the cvs repository). Removed that #347636 is blocked by this, as a component based approach, which is currently applied to build up GEF4, does not require Git. Added dependency to #363394, because this deals with the new Tycho-based build infrastructure, I am currently building up. Besides the Tycho build infrastructure, as a preparation to migrating the cvs repository it should get cleaned up. This includes: 1) Moving the GEF4 sub-module to its own git module (as done for Zest 2.0 already) 2) Moving all outdated plug-ins (especially the old releng plug-ins) into the archive folder (In reply to comment #8) > Besides the Tycho build infrastructure, as a preparation to migrating the cvs > repository it should get cleaned up. This includes: > > 1) Moving the GEF4 sub-module to its own git module (as done for Zest 2.0 > already) > 2) Moving all outdated plug-ins (especially the old releng plug-ins) into the > archive folder 1) is completed, as stated in bug #347636. As such, removing dependency on it. In order to enable local building with Maven/Tycho, the repository structure should be flattened before moving to Git. Having migrated to Git, the build job has to be provided with some tagging mechanism, so builds can be reproduced. OK, as the new build infrastructure is now completely in place, I think we are also good to go on with this one. From the experience I had with moving the GEF4 component, it would probably be easier to flatten the cvs repository structure before moving to Git, but we may also do that after having migrated, if this is intended. Anthony, what do you think? (In reply to comment #12) > From the experience I had with moving the GEF4 component, it would probably be > easier to flatten the cvs repository structure before moving to Git, but we may > also do that after having migrated, if this is intended. > > Anthony, what do you think? We should do whatever makes things better for Git. (In reply to comment #13) > (In reply to comment #12) > > From the experience I had with moving the GEF4 component, it would probably be > > easier to flatten the cvs repository structure before moving to Git, but we may > > also do that after having migrated, if this is intended. > > > > Anthony, what do you think? > > We should do whatever makes things better for Git. Well, I think we should then ask the Webmaster what he recommends. The cvs-git migration guide (http://wiki.eclipse.org/Git/Migrating_to_Git) lists the following procedure: Open a bug against Eclipse Foundation > Community > Git requesting the migration. Make sure your project lead is CC'd and add a +1 to the bug. Include detailed plans for your migration: -migration timeline -mapping of current code to new Git repos -your decision regarding existing code (archive or import) -A description for each of your repositories. The description will be seen in the web view: http://git.eclipse.org/c/ Considering the timeline, I would be fine with doing that asap. I don't have any changes open and I do not plan to start working on new bugs before we have migrated. Concerning the mapping to repos, its probably the best to leave the Draw2d/GEF-3.x/Zest-1.x together in one repo, and I suppose we want to transfer our history, right? (In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > From the experience I had with moving the GEF4 component, it would probably be > > > easier to flatten the cvs repository structure before moving to Git, but we may > > > also do that after having migrated, if this is intended. > > > > > > Anthony, what do you think? > > > > We should do whatever makes things better for Git. > > Well, I think we should then ask the Webmaster what he recommends. The cvs-git > migration guide (http://wiki.eclipse.org/Git/Migrating_to_Git) lists the > following procedure: > > Open a bug against Eclipse Foundation > Community > Git requesting the > migration. Make sure your project lead is CC'd and add a +1 to the bug. Include > detailed plans for your migration: > > -migration timeline > -mapping of current code to new Git repos > -your decision regarding existing code (archive or import) > -A description for each of your repositories. The description will be seen in > the web view: http://git.eclipse.org/c/ > > Considering the timeline, I would be fine with doing that asap. I don't have > any changes open and I do not plan to start working on new bugs before we have > migrated. > > Concerning the mapping to repos, its probably the best to leave the > Draw2d/GEF-3.x/Zest-1.x together in one repo, and I suppose we want to transfer > our history, right? An addition from my side. Now that we have cleaned the cvs repo up, we should leave the archive and not migrate it to the new git repository. Anthony, can I have your opinion of above listed points, so I can initiate the bug and we can that this done? (In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > (In reply to comment #12) > > > > From the experience I had with moving the GEF4 component, it would probably be > > > > easier to flatten the cvs repository structure before moving to Git, but we may > > > > also do that after having migrated, if this is intended. > > > > > > > > Anthony, what do you think? > > > > > > We should do whatever makes things better for Git. > > > > Well, I think we should then ask the Webmaster what he recommends. The cvs-git > > migration guide (http://wiki.eclipse.org/Git/Migrating_to_Git) lists the > > following procedure: > > > > Open a bug against Eclipse Foundation > Community > Git requesting the > > migration. Make sure your project lead is CC'd and add a +1 to the bug. Include > > detailed plans for your migration: > > > > -migration timeline > > -mapping of current code to new Git repos > > -your decision regarding existing code (archive or import) > > -A description for each of your repositories. The description will be seen in > > the web view: http://git.eclipse.org/c/ > > > > Considering the timeline, I would be fine with doing that asap. I don't have > > any changes open and I do not plan to start working on new bugs before we have > > migrated. > > > > Concerning the mapping to repos, its probably the best to leave the > > Draw2d/GEF-3.x/Zest-1.x together in one repo, and I suppose we want to transfer > > our history, right? > > An addition from my side. Now that we have cleaned the cvs repo up, we should > leave the archive and not migrate it to the new git repository. > > Anthony, can I have your opinion of above listed points, so I can initiate the > bug and we can that this done? Your plan sounds fine. You may want to email gef-dev to the other committers know that you are going to do the migration. OK, I raised bug #351232 to keep track of the migration process. Anthony, could you please +1 on this bug. (In reply to comment #17) > OK, I raised bug #351232 to keep track of the migration process. Anthony, could > you please +1 on this bug. +1, thanks for taking the lead on this. OK, the repo is now imported into http://git.eclipse.org/c/gef/org.eclipse.gef.git/ and I have changed the gef-nighty-tycho build to use the git repo instead of the cvs repository. Updated project meta-data to list the new Git repository instead of the old CVS one. Reminder: The web pages and the contribution guide will have to be updated as well. As a matter of cleaning up the repository, I would like to remove the ArcFix and TYCHO_BUILD_MIGRATION branches from the Git repository, so we only retain the maintenance branches as well as the master branch. Any objections? With the new Git repository in place, I think we will have to change our commit message standards (and update the contribution guide respectively). Git lists committer and date quite comfortable, as well as the branch, so only the bug and the changes are needed in the commit message. As such I would propose to in future use something like: [<BugNumber>] <BugTitle> <detailed description of changes> for example: [371820] Discontinued EDiagram Example Untracked the project. Updated Getting Involved web page to no longer list CVS and Bugzilla, but instead delegate to the Contributor Guide within the wiki, where we can consistently describe how to set things up and handle contributions. Removed ArcFix and TYCHO_BUILD_MIGRATION branches from Git. Updated contribution guide w.r.t. to commit message format, as has been agreed on in the mailing list. The last thing that has to be done is updating the contribution guide section that describes how to create contributions. Fabian augmented the contribution guide with instructions on how to create a contribution, so we are done with this by now. Resolving as fixed though. |