On 13-Aug-08, at 11:27 PM, Lukas Renggli wrote:

>> 1. Faster merges.  I have a couple of MC1 packages that are in the
>> many thousands of versions.  When I merge, it takes over a minute
>> before the dialog even pops up showing me the changes.  Making this
>> less of a chore would be a great boon to my development workflow.
>> 2. More efficient use of disk/network.  My MC repository is several
>> gigabytes, and I frequently transfer megabytes to commit a couple of
>> hundred bytes of source changes.  This isn't usually that big a
>> problem, but when working on a laptop with a small harddrive or a  
>> slow
>> connection, it's annoying.
>> 3. Cherry picking.  The worst part about merging with MC is that it's
>> all or nothing: you have to integrate every change someone has made,
>> or none of them.  MC2 lets you pick a few changes now, a few changes
>> later, and won't lose track of what you've done.
>
> 4. Extensible. MC2 is extensible in many aspects, the GUI is based on
> OB and the versioning model is simple and can potentially used for
> other data than code. Take the example the task of versioning files
> together with Smalltalk code. A thing that is nearly impossible in
> MC1, though in one of the first versions of MC2 I could implement a
> working prototype within half an hour wihtout being exposed to
> documentation or the code before.
>
>> ever running into.  MC2 was also written with portability much more  
>> in
>> mind, though MC1 is portable in practice (it works with full interop
>> on both Squeak and Gemstone), whereas MC2 is only portable in theory
>> so far.
>
> 5. Portability. For me this is one of the most important points. MC2
> clearly separates common, platform-dependent and GUI-specific code.
> The current implementation of MC hardcodes to many things to easily
> port to other Smalltalk dialects (GemStone did the impossible), and
> therefore people write their own libraries in VisualWorks, VST, GST
> and Dolphin to pull code from Squeak. This is a deadly one-way-road
> for open-source projects like Seaside or OB, because people working on
> these platforms are unable to contribute back conveniently. I hope
> that MC2 will be able to change that.


6. Slices

In MC1 version history is tightly coupled to package structure. In  
MC2, version history is associated with the code, not its  
organization, which means that you can reorganize the code without  
losing the history. Further, you can have different organizational  
schema operating at the same time. For example, one developer can  
organize things into packages, while another uses change sets, and  
they can still use MC2 to do merges. MC2 its self is organized into a  
set of packages, but I use UnionSlices to bundle them up into a single  
snapshot for release.

Colin