Community
Participate
Working Groups
This migration will take place Friday October 14. I think I have all the builder changes I need to implement this change in bug 350627. I've run a test migration before. I think SWT needs to update some of their build scripts to accommodate this change.
Just as a side note, the git filter branch operation to add the gitignore on this repo took 16 hours to run. These projects have a lot of tags in them.
Is this the last of the projects?
Remy, there is still the eclipse.releng guid projects to move. These are mostly releng features and the builder scripts themselves. In other words, nobody cares about them but me :-)
(In reply to comment #3) > Remy, there is still the eclipse.releng guid projects to move. These are > mostly releng features and the builder scripts themselves. In other words, > nobody cares about them but me :-) And me :-)
Note, there is currently a test repo here kmoir@build:/gitroot/platform> ls -ld *common* drwxrwsr-x 7 kmoir eclipse.platform 4096 2011-10-07 09:59 eclipse.platform.common.git
Running test build with updated location of doc bundles in new Git repo. http://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=e4b8c3554d81f5c5b11503abc8295504479035df
I have to redo this repo's migration. I accidentally copied org.eclipse.pde.doc.user from /cvsroot/eclipse instead of pde/. Which means it's not current content. I'll revert the map files to CVS for tonight's build. Yay.
Okay I reran the migration and everything seems to be fine. Test build was successful. Let me know if you see any problems. The ACLs should be the same ones that are on org.eclipse.releng for both the map files and the doc bundles. ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.common.git
Wow, the repo is almost 200MB, is this correct?
Yes. This is correct.
Oleg mentioned that the e4 projects map files hadn't been migrated to Git. Is there a plan to put them into Git in a separate repo from eclipse.platform.common? There are also build changes that are required. I don't have rights to do the migration because I don't have e4 commit rights.
(In reply to comment #11) > Oleg mentioned that the e4 projects map files hadn't been migrated to Git. Is > there a plan to put them into Git in a separate repo from > eclipse.platform.common? There are also build changes that are required. I > don't have rights to do the migration because I don't have e4 commit rights. I suggest entering a bug against e4 for that. I thought Paul had finished all the e4 Git migration, but if he left something out there might have been a reason for it.
The more I work with the eclipse.platform.common.git repo, the more I think it was a bad idea to put the map files into the same repository as the doc plug-ins. The only real reason speaking for a common repository is the ACL list (all SDK committers should have access to all these projects). But there are a few serious problems: 1. The repository is huge (180MB), and that's too much if you just need to set up a new workspace to do a build input for non-doc projects. 2. The mixing of meta-tags (I<date> and M<date> tags on the *.map files) and bundle qualifier tags (v<date> on the bundle repos) blows up the list of tags and could become confusing if we e.g. adopt the git-flow model with automated tagging from the build process and then choose the I<date> format also for the auto-generated bundle qualifier tags. 3. Git is not suited to the task for map file management. Git enforces a strictly linear sequence of commits to HEAD, so this will inevitably cause a lot of push conflicts when multiple components want to release their map files around the same time. In CVS, component map files can be committed independently and in any order without any conflicts. It was already a pain sometimes that the doc.map is shared among teams, and I don't want to have conflicts with everyone else. Especially because of point 3, I suggest to remove the maps from the common Git repo and leave org.eclipse.releng in CVS for now.
I think the last one can be tamed by applying Paul's suggestion from http://dev.eclipse.org/mhonarc/lists/e4-dev/msg05775.html. Rebasing shouldn't be that painful.
We can rerun the migration if the repo is too large to separate out the doc and map files. I agree that the repo is large. I mentioned last week in the planning call that the repo was around 200MB and was told that this was okay. I don't think that leaving our map files in CVS is a viable solution given that the Eclipse foundation will eventually be making the CVS read only.
(In reply to comment #14) The rebase flag solves the problem of merging incoming changes, but you still have to do Commit, Pull, wait, click OK, Push, and hope nobody pushed in between. Push is strictly sequential per Git repo, but it's parallel in CVS. (In reply to comment #15) > I don't think that leaving our map files in CVS is a viable solution given that > the Eclipse foundation will eventually be making the CVS read only. The Eclipse Foundation needs to understand that Git is an SCM. It is nice for Source Code Management, but it is not a panacea for all cases where a version management system is needed. See also bug 349048 comment 13.
(In reply to comment #14) > I think the last one can be tamed by applying Paul's suggestion from > http://dev.eclipse.org/mhonarc/lists/e4-dev/msg05775.html. Rebasing shouldn't > be that painful. I agree, rebasing is not painful and all committers should practice it if conflicts are found when pushing.
(In reply to comment #15) > We can rerun the migration if the repo is too large to separate out the doc and > map files. I agree that the repo is large. I mentioned last week in the > planning call that the repo was around 200MB and was told that this was okay. I'm not sure I understand why the size is such an issue. IMO more committers should have the docs locally replicated in order to keep the docs upto date. A smaller group of committers should be tagging each week. > I don't think that leaving our map files in CVS is a viable solution given that > the Eclipse foundation will eventually be making the CVS read only. This is the reality, CVS is going away and we need to find a new home for the maps.
Sorry, but none of the comments after comment 13 addressed any of the issues pointed out there. Please read my comment again. Rebasing is not the pain point. If for political reasons, we really can't stay with the best-suited repo tools for now (CVS), then we should at least keep the map files in a separate Git repository.
(In reply to comment #19) > Sorry, but none of the comments after comment 13 addressed any of the issues > pointed out there. Please read my comment again. Rebasing is not the pain > point. > > If for political reasons, we really can't stay with the best-suited repo tools > for now (CVS), then we should at least keep the map files in a separate Git > repository. A separate Git repository only solves the size problem. To me the size problem is the least interesting, because as Tom mentioned everyone doing build contributions is probably also contributing to doc sometimes, so they would need to keep a clone of that repository local anyway. You don't need to create a new clone every time you create a new workspace... Problems #1 and #3 are solved by having the build do the tagging. I don't understand problem #2. The map files themselves are currently only tagged once for each build by the builder. The tags that appear in the map files don't seem related to the tags appearing on the repository containing the maps.
> You don't need to create a new clone every time you create a new workspace... Really? So how can I share the same clone in a master and a R3_7_maintenance workspace if I need to have both workspaces running at the same time? With symlinks or hardlinks from the two working directories to the same .git directory? I doubt that EGit and cgit handle that seamlessly. A separate repository for org.eclipse.releng is definitely more trustworthy. > Problems #1 and #3 are solved by having the build do the tagging. Yes, but until then, it's unnecessary churn. > I don't understand problem #2. [..] > The tags that appear in the map files don't seem > related to the tags appearing on the repository containing the maps. That's my point. Why are they in the same repository if they are not related? Keeping separate things separate is usually a plus. If we want to use I<date> as common qualifier name, then the tags would suddenly fall together. It also sounds complicated for other workflows. E.g. the Releng Tools for CVS had Compare with > Released, so it was trivial to find out what changed between the current version in the workspace and the version from the org.eclipse.releng project. Things like that don't work any more if the real data (doc plug-ins) and the meta-data (maps) are mixed. I also wonder how it works with git-flow. You're working in branch "develop", so you can't easily look at the map files from branch "master" or "R3_7_maintenance".
As discussed in the eclipse planning call, I'll be creating a new repository to store the releng maps alone. The doc maps will continue to reside in eclipse.platform.common. I'll be starting this immediately and copying the CVS content again to run the migration. I'll let you know when it's ready and the map files need to be updated in the new repo.
As discussed in this morning's planning call, the decision was made to split the releng maps into a separate repo. This new repo is located here ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.releng.maps.git Please update your map files in it for the R3_7_maintenance and 3.8 stream builds in this repo. Since I had to rerun the migration from CVS again, the map files are in the state they were last Thursday night (October 13). You'll be happy to know that this repo is much smaller :-) kmoir@build:/gitroot/platform> du -sh eclipse.platform.releng.maps.git/ 11M eclipse.platform.releng.maps.git/
> Please update your map files in it for the R3_7_maintenance and 3.8 stream > builds in this repo. Since I had to rerun the migration from CVS again, the > map files are in the state they were last Thursday night (October 13). I've done this for all map files, including for R3_6_maintenance and R3_6_maintenance_Java7.
Thanks, closing.
