| [stellation-res] An overview of the task service concept |
Since I went and sort of spilled the beans on this, I thought it would be appropriate to send a description of what I'm working on to the list. Before I jump in, I'd also like to explain a bit of where this came from, and why we were initially keeping it quiet. The politics of budgeting in research are pretty complicated, and we're in a slightly awkward position. Lots of people like our work, but there's a lot of confusion about just how an open-source research project should be funded. Due to this, it became important for us to very quickly put together something really impressive, and really useful, which could demonstrate the value of our work to some of the other divisions of IBM, by showing how we can build something that directly positively impacts the work of people doing development at IBM. The task service is what we came up with: a way of quickly putting together something extremely powerful that provides a capability that no other SCM system out there currently does. (ClearCase does task-oriented change management, but not the pre-emptive conflict detection and messaging that we're including.) And the task service also provides a way of demonstrating the power of fine-grained support even before we have full fine-grained support in the repository. It was never our intention to keep this secret for long. We needed to get it together quickly, and so we decided to just go heads down and get a prototype together. The prototype was going to checked into the repository as soon as there was something worth checking in. Most of a prototype of what's described below is implemented; we're working on filling in the gaps. I'm attaching several things to this message: (1) The zip file that I meant to include in the message the other day, which contains the basic interfaces for our prototype. (2) A document describing how the task service is implemented using the Stellation messaging layer, written in OpenOffice format. (I can forward copies in Word format to anyone who'd prefer that.) (3) An overview document, describing the basic idea behind the service. I also did a UML model of the task system in argo, but it turns out that Argo didn't save large parts of my model, so the model isn't really worth sending. (If anyone really wants to see it, I'll be glad to send a copy. The class diagrams are mostly OK, but missing the text documentation and notes that I attached. Since a lot of the "Classes" in the diagram are modeling artifacts, and my annotations of what's real versus what's just a modelling artifact were lost, they're not very useful.) For the purposes of legalities: all of the following text and the attachments to this message are distributed under the terms of the Common Public License, as found at http://www-124.ibm.com/developerworks/oss/CPLv1.0.htm -Mark CONCEPT DOCUMENT: The Stellation Task Service I. Introduction When you first migrate from something like CVS to something like Stellation, one of the biggest changes – and one of the biggest advantages of systems like Stellation – is that you have easy to use, working lightweight branches. An actual working branch system is a huge leap forward, enabling all manner of useful capabilities, from managing multiple distinct releases of a system, to managing groups and change releases. Of course, there is a catch. When there are many branches in the system, it is hard to discern which branches are to be used for any given purpose. In particular, when a developer makes a change that can potentially be applied to many branches (for example, a bug fix), the rapid proliferation of branches because a significant problem, because there is no easy way for a developer to know which branches the changes should be merged into; and there is likewise no easy way for the owner of a particular branch to determine what changes from other branches should be merged in. The answer to this problem is to add another supportive layer over the branches, so that for many purposes, one doesn't explicitlycreate branches. Instead, you start to perform a change task, and a branch is created implicitly. Working in terms of change tasks adds both a layer of indirection that masks the complexity of branch management, and provides a hefty chunk of semantic information about changes that can be used to determine what changes are relevant to a given major branch. It is important to note here that this basic idea of task-oriented development is not original to Stellation. Many people in the SCM research area have worked very hard on developing and implementing this notion. In particular, Geoff Clemm's Asgard work, and his later work on UCM for ClearCase at Rational, are major inspirations for the kind of task model that I'm proposing for Stellation. II. Task-Oriented Change Management So the basic idea of task-oriented change management is that you rarely explicitly create branches. Branches are for big things, and there shouldn't be too many explicit branches. But for day-to-day normal work, you do not explicitly create branches, and you don't do explicit merges of changes to or from your parent branch. Instead, you start with a basic work branch, and inform the system that you are beginning to perform a change task. Change tasks are objects managed by the system that describe the work that needs to be done. They are categorized by change types – for example, “new feature implementation”, “bug fix”, “performance tuning”, “test implementation”, etc. The system maintains a complete list of the tasks that need to be performed, and developers have the ability to add to the task list, or to modify tasks in the list. So when you go to start making a change, you select the change task that you're going to be working on. The system implicitly creates a branch for you, and determines the correct merge behavior when the task is complete. (For example, a new-feature task would probably only be integrated into the branch for a major new system version; a bug fix would by merged into all branches containing the bug.) III. Task Management and Conflict Detection With a task-management system in place, we gain the ability to add a very interesting collaborative support feature: pre-emptive conflict detection and communication. The idea is very simple: the system knows what change task you're performing. It knows what resources you're modifying as a part of that change task. So if two change tasks derived from the same major branch are both trying to change the same resource, you've got a potential conflict. So, in the system server, we add support for a notion of resource reservations. A resource reservation is an indication that a resource is being changed as a part of some task, and that the owner of the task intends to check in a modified version. Whenever a developer starts to change a resource, Eclipse automatically sends a reservation request to the server. If there is already at least one reservation on the resource, the system sends a notification to the requester of the new reservation, and the holder(s) of the old reservation(s), notifying them of the impending conflict, and offering to open an instant messaging system between them if both parties are on-line. --
Attachment:
task.zip
Description: Zip archive
Attachment:
Stellation-task-service.sxw
Description: OpenOffice Writer document