links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
benefits of Squeak development via MC
Last updated at 12:48 pm UTC on 17 January 2006
Squeak is currently developed as a combination of packages and update-stream-managed code+image.

While this means that it is possible to make Squeak more modular by breaking out some code from the second part, making it into a package, and moving it to the first part, it also means that the development of part 2 is somewhat cumbersome. It has problems, some of which the use of Monticello for its development could help.

  1. Hard to perform conflict detection: when patches are harvested, any two patches are quite likely to not touch the same code, but this is not guaranteed. If they do conflict, and are harvested at the same time, unless detected, this situation can lead to one of them being partially included, with no one the wiser. This is currently dealt with by explicitly running Doug Ways ConflictChecker before including changes into the update stream, but would be more gracefully dealt with using MC merges.
  2. The integration bottleneck: them above is one example of the integration bottleneck - an activity that has to be centralized, because the stream of formal versions is centralized. One ad hoc solution is to have anyone run the CC and publish updates, but this doesn't prevent integration problems, it just lowers their cost by being optimistic about them. MC improves this situation in two ways -
    1. Separate packages can be integrated by their respective owners, instead of globally at the Squeak level.
    2. MC supports decentralized development, so that forks and merges are expected and supported by the tools.
  3. Hard to reconcile multiple projects. Squeak is fast becoming a family of projects instead of one project. This includes at least two images developed by the squeak-dev community (Basic and Full), and other project such as SqueakLand, Smallland, and Croquet each maintain separate update streams. In the update stream model, the sharing between these projects is costly, therefore it happens in bursts. If the sharing happened at the levels of specific MC packages, it would more flexible and cheaper to do.