Bugzilla – Full Text Bug Listing
| Summary: | Migrate GMF Runtime to git | ||
|---|---|---|---|
| Product: | Community | Reporter: | Anthony Hunter <ahunter.eclipse> |
| Component: | Git | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | Andreas.Muelder, apupier, pierre-charles.david |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 393265 | ||
|
Description
Anthony Hunter
There are pom.xml files in each of the folders in the CVS tree: % find . -name pom.xml,v ./pom.xml,v ./plugins/org.eclipse.gmf/pom.xml,v ./plugins/org.eclipse.gmf.runtime.common.ui.printing/pom.xml,v ./plugins/org.eclipse.gmf.runtime.common.ui.services.dnd/pom.xml,v ./plugins/org.eclipse.gmf.runtime.sdk/pom.xml,v Do we need these files? Now sure how to flatten the hierarchy and save these files. Hi, these files are required for the Tycho build. What do you mean by flatten the hierarchy? Do you plan to put every plugins at the root level? In this case, it will be harder to understand for which part a plugin is part of. It is possible to do it but it will require to update some poms for Tycho and personally I would prefer to keep the hierarchy. What is the purpose of flattening the hierarchy? It will be easier to migrate to Git? Regards, (In reply to comment #2) > What is the purpose of flattening the hierarchy? It will be easier to > migrate to Git? Correct, we need to do this to make migration work. This is what the other projects are doing so we should do the same. it seems that GMF-Tooling kept the hierarchy: http://git.eclipse.org/c/gmf-tooling/org.eclipse.gmf-tooling.git/tree/ We should ask them more details about it. > (In reply to comment #2)
> > What is the purpose of flattening the hierarchy? It will be easier to
> > migrate to Git?
>
> Correct, we need to do this to make migration work. This is what the other
> projects are doing so we should do the same.
This is actually incorrect, the first two Eclipse git repos I cloned also did not have a flattened hierarchy.
So I now have no idea why we have done this flatten step and it actually breaks the backwards compatibility of the CVS tree so I would have rather not flattened at all.
I think the requirement is really that the "stuff" we move to git is supposed to be under one root folder. Webmaster, can you confirm?
Usually we suggest that projects cleanup/organize/flatten in CVS before converting to Git, but it's up to the individual projects. Now if you had 5 or more CVS repos and wanted N number of Git repos, we(Webmaster) would probably push you to clean things up, or create fewer Git repos, but we haven't actually run into that situation yet. -M I think it is easiest if we flatten the hierarchy in git and have all of the bundles at the same level in the tree. Aurelien do you want to save the ./pom.xml,v files somehow or is it ok to overwrite and recover afterwards? Hi, it would be better to have a copy somewhere but i suppose that the CVS will keep it in history. I don't use often maven but it seems to me easier to use when there is a hierarchical structure. But I suppose that it will be possible to use a flat structure. So the idea will be to have several git repositories for each parts? (tests/examples/releng/plugins) regards, @Aurelien: I guess the pom.xml*,v* are temporary CVS files. They can probably be removed. @Anthony: Here is some feedback based on migrating GMF-Tooling to Git, and on daily usage of a hierarchical Git repo using Tycho for JBoss Tools. Git migration is performed by webmasters. It's not more difficult to migrate a hierarchical dependency than it is to move a "flat" one. Also, hierarchical repositories are very cool when using Maven since you have some inheritance of parent poms, and you can factorize some elements in "tests/pom.xml" for instance. It's a very common and useful thing. You don't NEED TO flatten repo to move to Git. And I don't think you'll gain anything by flattening repo. Also, I simply think given development resources on GMF-Runtime, this is simply not do-able: restructuring would break builds and so on, and no-one will have time to spend on fixing it soon. The project would loose some HP (Health Points). I highly recommend not changing repo layout and move to Git as-it. I would highly prefer keeping the hierarchy, it will avoid to break the build. I don't think that we have enough resources in GMF-Runtime committers - Anthony and I - to repair the build in a reasonable amount of time. Note that we need to make use of the CBI build to participate in the LTS. I have already flattened the hierarchy on a few other modeling projects when we migrated to git, I will get the build going on these before we make a final decision on GMF runtime. I have looked at other projects and the ones I am a committer on and the extra folders just do not add any value. It also adds the extra orphan pom.xml in various folders. I will flatten the hierarchy as I planned and the top level pom.xml will be the one in the org.eclipse.gmf.runtime.releng bundle. I do not mind fixing the build as I am creating new builds for four other projects and will fix the GMF Runtime at the same time. /cvsroot/modeling/org.eclipse.gmp/org.eclipse.gmf.runtime is ready to migrate to git . Can you make sure that /cvsroot/modeling/org.eclipse.gmp/org.eclipse.gmf.runtime/archive does not make it into the repository? Otherwise /cvsroot/modeling/org.eclipse.gmp/org.eclipse.gmf.runtime/* should be in the git repo. Done. CVS has been frozen, and the Git URLs are: ssh://committer_id@git.eclipse.org/gitroot/gmp/org.eclipse.gmf-runtime.git http://git.eclipse.org/gitroot/gmp/org.eclipse.gmf-runtime.git -M. I am getting the error when trying to push : ssh://ahunter@git.eclipse.org/gitroot/gmp/org.eclipse.gmf-runtime.git: error occurred during unpacking on the remote end: unpack-objects abnormal exit Seems from searching around that this is a permission problem on the eclipse.org server yes, permission problem at eclipse.org % ls -l /gitroot/gmf-notation/org.eclipse.gmf.notation.git total 32 drwxrwsr-x 2 ahunter modeling.gmp.gmf-notation 4096 2012-11-05 11:02 branches -rw-rw-r-- 1 ahunter modeling.gmp.gmf-notation 126 2012-11-05 11:02 config -rw-rw-r-- 1 ahunter modeling.gmp.gmf-notation 45 2012-11-05 11:02 description -rw-rw-r-- 1 ahunter modeling.gmp.gmf-notation 23 2012-11-05 11:02 HEAD drwxrwsr-x 2 ahunter modeling.gmp.gmf-notation 4096 2012-11-05 11:02 hooks drwxrwsr-x 2 ahunter modeling.gmp.gmf-notation 4096 2012-11-05 11:02 info drwxrwsr-x 4 ahunter modeling.gmp.gmf-notation 4096 2012-11-05 11:02 objects drwxrwsr-x 4 ahunter modeling.gmp.gmf-notation 4096 2012-11-05 11:02 refs % ls -l /gitroot/gmp/org.eclipse.gmf-runtime.git total 32 drwxrwsr-x 2 root cvs 4096 2012-12-05 14:29 branches -rw-rw-r-- 1 root cvs 126 2012-12-05 14:29 config -rw-rw-r-- 1 root cvs 44 2012-12-05 14:35 description -rw-rw-r-- 1 root cvs 23 2012-12-05 14:29 HEAD drwxrwsr-x 2 root cvs 4096 2012-12-05 14:29 hooks drwxrwsr-x 2 root cvs 4096 2012-12-05 14:29 info drwxrwsr-x 4 root cvs 4096 2012-12-05 14:29 objects drwxrwsr-x 4 root cvs 4096 2012-12-05 14:29 refs The repo is likely in the wrong spot as well, we have: /gitroot/gmf-notation /gitroot/gmf-tooling /gitroot/gmp Should the latter not be gmf-runtime rather then gmp? Bumping to major as our source repository is now down as a result. Sorry about the delay. I've fixed the permissions, and moved the repo. URLs are now: ssh://committer_id@git.eclipse.org/gitroot/gmf-runtime/org.eclipse.gmf-runtime.git http://git.eclipse.org/gitroot/gmf-runtime/org.eclipse.gmf-runtime.git -M. Thanks |