Architecture Council/Meetings/March 25 GitBof

This page covers the VCS and git BoF's held at EclipseCon 2009. The git proposal was the result of these two BoF's.

Executive Summary: git Proposal

• Denis proposal: open 5 bugs: (current git bug depends on all of these - Bug 257706)
  • (1) Bug 270860 Get the egit project underway - how to improve the egit plugin
  • (2) Bug 270850 Startup a git repository to practice on the tooling (Martin?) - maybe a vserver at git.eclipse.org with someone else as root.
  • (3) Bug 270852 How do we delete code in git?
    • (a) Require CVS for parallel IP
    • (b) Use two databases - tainted and blessed?
    • (c) Keep track of deletes so they don't come back automatically
  • (4) Bug 270854 Deprecate the old tools - timeline to remove the old tools. Denis doesn't mind have CVS around for a while because it's very low maintenance.
  • (5) Bug 270856 Bounce the idea of a DVCS with the Eclipse legal team.

VCS BoF

• 24 March 2009 at EclipseCon
• Attendees (apologies for any omissions or errors)
  • Alan Shutko (Express Scripts), Shawn Pearce (Google), Jack Repenning (CollabNet), Dennis Beasley (Alcatel-Lucent), Manuel Woelker (EclipseSource), Nick Crossley (IBM via telelogic), Doug Gaff (Wind River), Denis Roy (Eclipse Foundation), Karl Matthias (Eclipse Foundation), Scott Rosenbaum (Innovent Solutions), Cedric (Obeo), William Pierce (Obeo), another Obeo guy, Martin Oberhuber (Wind River)
• What do you use for VCS and what are you interested in?
  • Alan: Moving company off of PVCS onto CVS.
  • Shawn: everything, but git is his main thing. Perforce is used internally in Google. There is a git-P4 connector. wrapped PVCS in git, moved people to git.
  • Dennis: SCCS customized, 4 Clearcase versions, Sublime (SCCS plus stuff), Perforce, some SVN
  • Manuel: CVS, SVN, looking at git
  • Nick: IBM synergy
  • Jack: SVN
  • Doug: CC, SVN, git, CVS
  • Cedric: project lead of EMF compare
  • William: model-to-model transformations
  • Martin: git for E4
• General discussion
  • Some discussion about parallel development and CVS's lack of support - I didn't capture anything intelligent.
  • Why did RTC create another VCS? Nick: says they needed it because of the workflow model.
  • Doug G: People need diff merge tools: binary comparisons, semantic merges.
  • Jack: definition of binary needs more. Also, code beautification and encoding (UTF-8, shift-jis) also required. Semantic analysis could potentially be a black hole. How deep is the analysis?
  • Manuel: don't worry as much about semantic merges. Unit tests, integration tests, and human reviews are still critical. VCS systems should be content agnostic, and merge systems should be content aware.
  • Nick: I somewhat disagree. I certainly don't totally trust an automated merge tool, but you need a merge tool to make suggestions and needs some semantic analysis.
  • Jack: Well yes, there will always be a harder case. Merge tools should make an attempt, and the tool should know when it can't make the semantic analysis correctly.
  • Shawn: one of the social constructs of open source is that if your branch or patch doesn't apply correctly, compile, or pass unit tests, it goes back to the submitter for rework.
  • Jack: yes, commercial companies often put the merge job onto someone else other than the developer.
• Git discussion
  • Denis: please pick! We're open to git, but stop adding and adding.
  • Alan: when will SVN merge well?
  • Jack: work in progress! There's stuff in the pipeline, but 1.7 will not be everything that 2.0 wants to be.
  • Manuel: the Eclipse support is what's making the SVN switch so hard. People switched to SVN early, and realized the Eclipse integration wasn't great. Tortoise SVN is great.
  • Karl: The Eclipse community has to commit to the tooling for git!
  • Martin: we can't throw out CVS easily. But we can do git without having the tooling right away.
  • Nick: the licensing issues were a real issue with SVN.
  • Martin: what pissed me off about SVN was performance. From Europe it was just bad, and the performance issue wasn't client-dependent.
  • Shawn: we wanted Egit to be hosted on Eclipse.org, which is why it's BSD licensed. But the plug-in is far from complete, and I need some help from the community.
  • Denis: 12 or so projects are on SVN. Almost all the new ones that come up go to SVN.
  • Manuel: well, the newer projects might be willing to switch to git.
  • Denis: IP process: we have the requirement to permanently delete code. Easy in CVS. Hard in SVN. We have separate repositories on SVN to minimize downtime.
  • Shawn: described how this is done in git. But how late is this being identified? Are there ways to avoid code being even submitted.
  • Karl: the projects have hugely different social norms, and some projects aren't as good at the IP process.
  • Martin: well, as today's keynote said, shit happens. You just can't prevent it.
  • Doug: parallel IP process.
  • Martin: perhaps libraries in parallel IP could go into a temporary repository.
  • Nick: well SVN obliterate command should be coming. Why bend the process for this?
  • Denis: force parallel IP into CVS until it's approved. CVS is the easiest to blow away.
  • Doug: does this parallel IP process make git more palatable?
  • Denis: it makes it less un-palatable. Look, the issue is having too many choices for VCS. It's hard for newcomers.
  • (Discussion about complexity of revision control when multiple repositories are required to build a project. No good notes from me.)
  • Denis: "did I say fuck yet?"
  • Scott R: everyone is acknowledging that there are better systems than CVS. Don't we need to accept some pain so we don't get left behind?
  • Martin: yes, and we're encouraging some people to move forward. We have to improve the tooling by experimentation. We need to experiment with git, too.
  • Denis: you don't need me for that.
  • Manuel: well, for CVS import, we need everyone on one server.
• Decision to adjourn and continue the discussion in the git BoF the following night.

git BoF

• 3/25/2009 at EclipseCon
• Attendees and "Why are you here?" question.
  • Manuel: CVS is the cobol of source control management. I'd really like to have git at the foundation.
  • Ketan: Similar to what Manuel.
  • Windel: SVN admin. Using perforce now. Trying to find out about git.
  • Philippe: CVS doesn't work in our company. Bad habits working around CVS. Lack of branching.
  • Andy: Using SVN, but not happy.
  • Tim: Their team is still on CVS. Trying to determine whether to skip SVN and go straight to git.
  • Karl: webmaster
  • Denis: webmaster
  • Daniel: don't like CVS. Where is eclispe going?
  • Boris: work for IBM. Originally helped build CVS plugin in eclipse.
  • Shawn: original author of current eclipse plugin for git.
  • Alex: git BoF.
  • Late arrival - I didn't get the name.
• Discussion about getting patches in and release cycles.
  • Manuel commented about having to maintain patches moving forward.
  • Git is being proposed as a way to maintain a patch for a long time until the community has time to review it.
• git
  • Denis: it's clear that the contributors want git, but how do the committers feel?
  • Boris: well, I trust CVS. I don't think we can move to git until we have stronger tooling.
  • Karl: consensus from yesterday: the foundation wants to give you the tools you need. It seems like the easiest thing for us to use is to pick a version control system to migrate off of onto git. But we need good tooling to support this. We need to get people helping with the tooling first, though. It's a hard sell to projects without the tooling.
  • 20 projects using SVN (corrected from yeserday)
  • Karl: "I think git is sweet"
• egit plugin
  • Egit is the plugin, jgit is the library.
  • Egit is EPL, jgit is BSD and will need EDL to be hosted at eclipse.org or will need to go to orbit. Prefer EDL. Doug G offered to help Shawn with the Dual Licensing discussion.
  • Some discussion about egit project proposal status. (Egit draft proposal is http://www.eclipse.org/proposals/egit/, from http://wiki.eclipse.org/EGit/Proposal. There's also a background of Git at http://wiki.eclipse.org/Git_for_Committers. PS Currently maintained at Google Code http://code.google.com/p/egit/ - Alex)
• Dennis made the proposal that appears at the top of this page.