On Thu, Aug 14, 2008 at 12:42 AM, Colin Putney <cputney at wiresong.ca> wrote:

>
> 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
>

This is the killer app for me :)  It means I can version my closure
bootstrap, which is too ticklish to maintain as packages.  Is there a way to
take existing changesets and make them slices?  How do MC2 slices integrate
with changesets?  Do slices have names that match changesets or what?  If
I'm in a changeset do changes get added to the corresponding slice
automatically?  Where can I read up on this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080814/2160a008/attachment.htm