Community
Participate
Working Groups
I'm not sure about the political and build impact but would it be possible that the e4 project moves to git?
It sounds fine, as long as the committers working on e4 consider the git tooling to be acceptable, and it is not too difficult to get the build working against git. Note that the bundles involved in the 4.0 release are no longer part of e4 and will likely need to move to git at the same time as the rest of the Platform project. Last I heard, CVS support at the Foundation is eventually being phased out so all projects will eventually need to migrate to git. I.e, there is no political impact. Everyone will eventually move so it is just a matter of timing.
We are aiming to release EGit 0.9 for Helios SR1. It would be great to get some feedback in the coming weeks to see what is missing that the e4 team would need in order to move from the tooling POV.
We have at least one component that could really benefit from git. http://dev.eclipse.org/mhonarc/lists/e4-dev/msg03529.html But the building from git will take significant developer effort. PW
How about an excuse to move away from map files and do things better and more the "Git way" ? We would have two branches, we could always make master be production essentially. We would have a "dev" branch where all active development happens. Committers would then cherry pick any changes from the dev branch to master. When we ship a major release, we create a "stable-3.7" branch that would serve as a place for changes for the maintenance releases. Any commits could be cherry picked to that branch and then tagged. Let's use this chance for discussion of how we can do things better. I'll cc Shawn as he has a lot of experience with different Git workflows.
(In reply to comment #4) > How about an excuse to move away from map files and do things better and more > the "Git way" ? I'm not sure map files are really that bad. I think of them like an automatic maintainer that pulls different repos together for building. The model seems quite a good fit for largely distributed teams working on different repos. But maybe it's the granularity that changes. Currently it's like each bundle is in it's own repo. I could imagine that the granularity will change in that there might be a repo per (sub-)component.
I'm interested in massaging the process closer to the "git way" (use the tool how it is meant to be used). But won't it peg us to one repo per bundle/plugin? In each build, if a plugin hasn't changed then it's qualifier must not change (even more important with our use and mirroring of the p2 repos). PW
(In reply to comment #6) > I'm interested in massaging the process closer to the "git way" (use the tool > how it is meant to be used). > > But won't it peg us to one repo per bundle/plugin? In each build, if a plugin > hasn't changed then it's qualifier must not change (even more important with > our use and mirroring of the p2 repos). This might be a bit sick, but if you can prove to yourselves that a plugin is only impacted by the files within a single subdirectory, then you can ask git what was the last commit that touched that subdirectory. Assuming all plugins are at the top level of a repository: for p in org.eclipse.* do rev=$(git rev-list HEAD -- $p) done Having this, we can then for example chose to only build plugins that were changed since the last stable build: last=$(git rev-parse --verify last-stable) for p in org.eclipse.* do rev=$(git rev-list last-stable..HEAD -- $p) if [ -n "$rev" ] then echo "Need to build $p" fi done git update-ref refs/heads/last-stable HEAD $last I don't know all the p2y bits needed to actually build a plugin, or save its build off, or how to say that this build is something we're keeping forever and would reuse build products from vs. something we are discarding as a nightly, but that's the general approach. If you are build this up in Java based tooling, you can do this with JGit calls instead of running off to the C command line.
(In reply to comment #7) > I don't know all the p2y bits needed to actually build a plugin, or save its > build off, or how to say that this build is something we're keeping forever and > would reuse build products from vs. something we are discarding as a nightly, > but that's the general approach. Currently, everything is always built. Nothing is built incrementally. Plugins are fetched from CVS using a tag. That tag is also used to replace the "qualifier" in the version string. Thus, as long as the tag doesn't change, the version will be the same. This leads p2 to think that a plugin did not change. All the tags are collected together with repository information in a map file. That map file is used to generate Ant scripts that will fetch the plugins from CVS. A tool exists to tag a plugin and update a map file in one step. That can be updated to work with Git as well. The question remains, is there a better story for maintaining and aggregating a 'list of tags from various repos' in Git?
(In reply to comment #8) > > The question remains, is there a better story for maintaining and aggregating a > 'list of tags from various repos' in Git? Yes, use git submodule. In submodule world you have a new repository that just lists out the other repositories it imports. For each repository it has a single commit SHA-1 which tells you exactly what revision to check out for that repository. This lets you track revisions rather than tags, which means you don't necessarily need to drop a tag on every build in every repository. If the qualifier is based off a revision in CVS, you could replace it by munging the output of git describe in the repository. Take the output of `git describe` which is e.g. "v0.8.4-370-gf50f88f" and reformat it as "0.8.4.00370_f50f88f". The tail will tell you what revision was used without necessarily needing to make a tag in git, while the 370 part is an incrementing number as the number of commits since 0.8.4 tag was created. Releases at an actual tag would thus have 00000 here.
We've been having this discussion in CDT too. I think the current thinking is we want multiple plugins versioned in a single repo (rather than versioned per-plugin and pulled together with submodule). Doug pointed out that building / extracting plugins from a single checkout is possible using PDE build (bug 316212) using the search path functionality: bug 128846
I've opened bug 325750 to move the deeplinking sub-component to e4. If we include one component in one git repo, then maybe query code like Shawn suggested might be the most compatible. 1) commits go into the dev branch. Nightly builds are run from the HEAD of dev branch. 2) commits are promoted to master (or HEAD, whatever). This is tagged for the I builds 3) for every plugin to be processed by PDE, the qualifier will be the last tag that included a change for that plugin. That get's around the problem that technically all plugins have the same (latest) tag. There are 2 parts of the process that are not clear to me. 1) how do we get the dev commits into the master branch. Who's supposed to do this (aside from auto-promoting which seems to me to defeat the purpose, it's not likely to be one person)? Will we run afoul of the IP hooks [1] if one person tries to promote dev to master? 2) where does gerrit fit in? does gerrit replace the IP hooks mentioned in #1? Does it simply compliment them? Or has nothing to do with them? [1] http://wiki.eclipse.org/Git#Notes_on_DVCS PW
I've moved the mechanics of the build discussion to bug 289838 PW
We've moved 3 components over to git. We're still working with bug 289838 to be able to build them. Deeplinking: git://git.eclipse.org/gitroot/e4/org.eclipse.e4.deeplink.git git://git.eclipse.org/gitroot/e4/org.eclipse.e4.utils.git Starting point for a "work with p2" solution: git://git.eclipse.org/gitroot/e4/org.eclipse.e4.installer.git PW
I have updated the basebuilder used for e4 to the org.eclipse.releng.basebuilder tagged v20101019 + pde.build from I20101019-0800 + org.eclipse.egit.fetchfactory from bug 289838. I also updated deeplink's map files to use git. A test build using this was mostly successfull, I expect to run this week's e4 build using git.
I've added scripts and instructions to the wiki for doing an e4 git build submission to update our map files. http://wiki.eclipse.org/E4/Git PW
This bug was for the full e4 project. If I get this right here, only a part has moved. Shall we leave the bug open or shall I open a bug for the individual componenents? E.g. UI (which is the core of the e4 development) would be cool if it moves to git.
(In reply to comment #16) > This bug was for the full e4 project. If I get this right here, only a part has > moved. > > Shall we leave the bug open or shall I open a bug for the individual > componenents? E.g. UI (which is the core of the e4 development) would be cool > if it moves to git. the UI component now actually consists of 3 "bits": The modeled workbench and CSS has actually graduated to Eclipse Platform UI. We need to create a ui container at the top level and move these up. The context DI code has graduated to Eclipse Platform Runtime. It also needs to be moved. As these will be part of the 4.1 SDK build (and not the e4 build) they'll have to remain CVS for now. There would be examples, the Model Editor tool, and perhaps a few other pieces left in the e4 UI component. I don't see any harm in leaving this open for now, although I'm open to other suggestions. PW
I open a new bug for the move of the tooling to git.
