A new approach to configuration management implemented in VisualAge/Java Micro Edition. They are also used in the EclipseIde.

See http://www.jugs.ch/html/events/2001/xpteamsupport.html for an abstract (in German).

''So how do TeamStreams support ExtremeProgramming practices? I only saw a presentation at XP 2000 in Cagliari, and I remember not being too impressed at the time. However, I don't know how things have developed in the meantime, so the picture might be much clearer by now. -- HaskoHeinecke''

I saw the demo at Cagliari, and I was VERY impressed.  The model of source code control matches the needs of XP very closely.  The idea is that a group of people share one or more TeamStreams.  A team stream has a set of items under source code control.  You have versions of those on your computer, as well.  

The main operation on a team stream is ''synchronize''.  This operation compares the versions of the items on your computer with the version in the team stream.  If your computer has older versions, they get updated.  If there are conflicting changes (i.e. the team stream has a new version, but you have a newer version, too) then your computer gets the newest version from the team stream and goes into a mode where it shows you the conflicts and lets you resolve them by merging them.  But if the versions on your computer are all newer than the versions in the team stream, the team stream gets updated with the newer versions.

So, suppose you have been programming for awhile and want to integrate.  You synchronize.  Perhaps nobody else has synchronized since you have, in which case the team stream is updated and you go on.  Perhaps there are some recent changes, in which case your computer gets them.  Perhaps you have to resolve conflicts, perhaps not.  In any case, you run your UnitTest''''''s again, and when they pass you will synchronize again.  You might have to do this several times if other people are making changes at the same time as you are, but eventually your changes get put on the team stream and you have finished integration.

So, TeamStreams support XP very well. -- RalphJohnson

Some other version control tools have this as well. ClearCase/UCM has team streams called ''Integration Streams'', AccuRev has streams (of all sorts), SpectrumSCM has streams but calls the product-wide branches. -- BradAppleton

''Integrating changes and three-way diffs are basic functions of any usable configuration management system. However, I seem to remember that in the presentation, they described TeamStreams as a radically different approach to config management. In particular, they believed it is superior to EnvyDeveloper. I don't quite remember what the difference was, but I would like to know. Maybe it will become clearer then how TeamStreams supports XP better than Envy or CVS. -- hh''

They didn't say it was radically different.  They said it was simpler, easier to use, and just as powerful.  It was developed by the people who made EnvyDeveloper and they claimed that it was as powerful.  I could tell it was much simpler.  Setting up a team stream might be complicated (I don't know) but using one is easy; you just say "synchronize".  If you have to merge then after you are done you synchronize again, and repeat until you don't have to merge.  It seemed simple to implement as well as to use.

''So are you saying, it supports XP better because it's simpler? I could agree with that. After all, simplicity is one of the ExtremeValues. But then, what about the hierarchy of streams that you can create. Does that fit in the XP process, or would you rather not use this feature? And I understood going back to a previous project state was not (yet?) well supported. Isn't this necessary even in an XP project?''

----

KaiUweMaetzel claimed in his talk about TeamStreams that they can be emulated using CVS (losing the feature of versioning independence). How would that be? Where can I find more information about this? -- DierkKoenig

This is basically how CVS works.  You checkout files from the repository. You can then either *commit* your changes or run *update* to get other's changes.  If you try and commit a file that has been committed since you last checked it out you are warned about the conflict.  You could emulate by having a "synchronize" script that calls update and commit and runs a program that walks you through the conflict resolution.  Other SCC systems use this (e.g., Perforce, ClearCase; ClearCase also has a mode where updates happen automatically in real time). -- DaveTauzell

----
See ConcurrentVersionsSystem