Avi Bryant <avi at beta4.com> wrote:
> > A. I get strange debuggers and syntax error notification with WeakSets
> > when merging an mcz file into an empty package. Is this a known issue?
> > if not I'll document it better and rereport.
> I've seen it occassionally as well.  I have no idea why it happens.  If
> you have a way of reliably reproducing it, that would be useful.
"Enter a clean 3.6B, load MC. Create an empty Refactory package. Open an
existing Refactory.mcz, merge it" has been pretty reliable in
reproducing it for me. I'll explore and give a recipe and applicable
file when I'm done tweaking the RB 3.6 release.

> > B. Doing the above merge, I get a conflict about the new class
> > categories introduced, which isn't really a conflict, is it?
> Why are you merging into an empty package rather than simply loading?
I'm a cautious guy. Also, first time I did this, I saw conflicts - with
methods that the RB overrides, but actually exist in the base image.
That was unexpectedly useful, because the RB versions were stale. 
Anyway, I'd like to avoid the remotest possibility of changes slipping past 
me. So load isn't a button I'm likely to ever use...

> Anyway, no, class categories shouldn't conflict.  The problem is that the
> OrganizationDefinition is treated as one atomic definition - so if two
> people add or remove categories concurrently it'll show up as a conflict.
> I'm not sure what the best way of solving this is - since I want to keep
> the category order, I don't want to split them up into independent
> CategoryDefinitions.  Perhaps certain kinds of definitions can be made to
> know how to resolve their conflicts automatically.
Note that the conflict was between having categories, and having none,
not a different order. That sounds pretty spurious to me.

> > C. After doing keep, the working copy is marked dirty, while in fact it
> > is identical to the package merged (I think). Any reason?
> 
> The dirty flag is really crude right now - basically any time a method is
> compiled in the package it gets set.  So it's always only a hint as to
> whether or not the package is really dirty.  The Changes button is a
> better indicator.
Ok.

> (The Changes button, by the way, gives you the changes *relative to the
> selected repository*.  So you'll get a different patch depending on what
> you have selected).
I'll have to explore that, then. Haven't touched it so far.

BTW, I've just upgraded from 13 to 9. Can Colin and you, for my sanity,
please keep the versions (at least in SM) monotonously rising?

Yet another issue - if a numbered file is missing in my repository (say, 4)
MC keeps wanting to name my next version that, instead of going for 
highestFound + 1. A little annoying...

Thanks for MC guys - I wouldn't be bitching about such small things if it 
wasn't so good. 

Daniel