<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Aug 14, 2008 at 12:42 AM, Colin Putney <span dir="ltr"><<a href="mailto:cputney@wiresong.ca">cputney@wiresong.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="Wj3C7c"><br>
On 13-Aug-08, at 11:27 PM, Lukas Renggli wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. Faster merges. I have a couple of MC1 packages that are in the<br>
many thousands of versions. When I merge, it takes over a minute<br>
before the dialog even pops up showing me the changes. Making this<br>
less of a chore would be a great boon to my development workflow.<br>
2. More efficient use of disk/network. My MC repository is several<br>
gigabytes, and I frequently transfer megabytes to commit a couple of<br>
hundred bytes of source changes. This isn't usually that big a<br>
problem, but when working on a laptop with a small harddrive or a slow<br>
connection, it's annoying.<br>
3. Cherry picking. The worst part about merging with MC is that it's<br>
all or nothing: you have to integrate every change someone has made,<br>
or none of them. MC2 lets you pick a few changes now, a few changes<br>
later, and won't lose track of what you've done.<br>
</blockquote>
<br>
4. Extensible. MC2 is extensible in many aspects, the GUI is based on<br>
OB and the versioning model is simple and can potentially used for<br>
other data than code. Take the example the task of versioning files<br>
together with Smalltalk code. A thing that is nearly impossible in<br>
MC1, though in one of the first versions of MC2 I could implement a<br>
working prototype within half an hour wihtout being exposed to<br>
documentation or the code before.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ever running into. MC2 was also written with portability much more in<br>
mind, though MC1 is portable in practice (it works with full interop<br>
on both Squeak and Gemstone), whereas MC2 is only portable in theory<br>
so far.<br>
</blockquote>
<br>
5. Portability. For me this is one of the most important points. MC2<br>
clearly separates common, platform-dependent and GUI-specific code.<br>
The current implementation of MC hardcodes to many things to easily<br>
port to other Smalltalk dialects (GemStone did the impossible), and<br>
therefore people write their own libraries in VisualWorks, VST, GST<br>
and Dolphin to pull code from Squeak. This is a deadly one-way-road<br>
for open-source projects like Seaside or OB, because people working on<br>
these platforms are unable to contribute back conveniently. I hope<br>
that MC2 will be able to change that.<br>
</blockquote>
<br>
<br></div></div>
6. Slices<br>
<br>
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.<br>
<font color="#888888">
<br>
Colin<br></font></blockquote><div><br></div><div>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?<br>
</div></div></div>