Tags: OpenJDK
Mark Reinhold:
Source-code management for an open JDK, Kelly O'Hair: Teamware, Mercurial, and SCCS revs that go bump in the night and Martin Englund:
Migrating from TeamWare to a new SCM have posted a series of blogs (linked above) talking about the source code managment thinking as we move to the open JDK project.
I don't have much to add to what they've said. I just wanted to give them a little visibility, so go to their blogs if you have comments or questions.
I do want to elaborate a little on how we use TeamWare today to manage the Java SE workspace, and other related workspaces. There's an important distinction with our model and the CVS style single-repository model.
In Teamware, when you create a child workspace from a parent, that child workspace can in turn be used to create further child workspaces. And then the parent-child relationship can later be changed. This makes it possible to create an arbitrary directed graph of workspace relationships, and is pretty flexible.
The development group uses this to create a tree of repositories. I don't know exactly how they're mapped out, and the exact map isn't important. The pattern of these repositories is to have a top-level master controlled by Release Engineering, and multiple levels of child workspaces. It is from that repository which RE does the weekly build to create the public bundles. Individual component teams (e.g. Networking or JDBC or Swing, etc) have their own child workspace, and each developer within one of those teams will have multiple child workspaces derived from their team workspace.
An individual developer working on a something (e.g. fixing a bug) will create a child workspace for that work. Because each workspace can in turn be used to create child workspaces, any work that developer does in the workspace is insulated from everybody else. If they don't like the result, they can just delete the directory structure containing the work. etc.
Source:
weblogs.java.net
