On Sep 18, 2005, at 3:32 PM, Colin Putney wrote:

>
> On Sep 18, 2005, at 3:56 PM, Avi Bryant wrote:
>
>
>> Sure.  Daniel's currently tweaking MC's merge behavior to be more  
>> like what Bert's MCConfigurations do, to make it a better default  
>> choice: if the local version is an unmodified ancestor or  
>> descendant of the version you're merging in, then there's no need  
>> to treat it as anything but a load.  Given that, I would suggest  
>> changing the names for the two operations to "Revert" and  
>> "Upgrade", which are hopefully more self-explanatory.
>>
>
> Hang on now. I don't think we want to be quick to change the names  
> of things.
>
> The names "load" and "merge" were carefully chosen, have well  
> defined meanings, and have been in use for several years now in the  
> Squeak community. They also match the terms used in the wider  
> Smalltalk and (to some extent) source control communities. Even if  
> we can convert certain merges into loads, that's an optimization.  
> We needn't change the UI to accommodate it.

What I'm really talking about isn't so much optimization or even  
names, but how we map possible scenarios to operations in the UI.   
Let's look at some possible use cases:

a) I am a user, and not a developer, of a package.  I haven't  
modified it in my image.  I want to be using a later version.
b) I am a user of a package.  I have made some minor changes in my  
image.  I want to be using a later version, but not to lose my local  
changes.
c) I am a user of a package.  I have made some minor changes in my  
image.  I want to use a later version and discard my local changes,  
since I believe they are now unnecessary.
d) I am developing a package together with some others.  I haven't  
modified the package in my image, but I want to be using some recent  
changes from someone else.
e) I am developing a package together with some others.  I have  
modified the package in my image, and would like to test how these  
changes integrate with recent changes made by others.
f) I am a developer or harvester and I have been using an  
experimental version of a package.  I have finished evaluating these  
changes, and would now like to switch to an older version, or a  
different experimental version.

As it stands, we expect people to use Load for a, c, d, and e.  We  
expect people to use Merge for b and d.  Note, however, that the  
basic intent behind a and b is the same (user wanting to update a  
package), as is the basic intent behind d and e (developer wanting to  
use changes from collaborator).  The major difference between each  
pair is whether or not local changes have been made: the user or  
developer has to manually check the modified flag and make the choice  
to Load or Merge based on that.  I'm not particularly concerned about  
this for developers: they should be attuned to things enough to  
realize whether d, e, or f applies.  But we've seen several cases of  
users not knowing that this choice needed to be made, getting  
accustomed to using Load every time, and then being unhappy with the  
results when they have local changes.

What I'm proposing is that we change the partitioning so that there's  
one operation (which I was proposing we call Upgrade) that gets used  
in cases a, b, d, and e, and another operation (which I was proposing  
we call Revert) to be used in cases c and f.

Or to put it another way, I would like to change the default  
operation - the one users and tools are most likely to use and be  
familiar with - from Load to Merge.  The main requirement to allow us  
to do that is to make Merge as simple to use as Load in the cases  
where it is semantically equivalent, rather than always popping up a  
window, changing the ancestry, and marking the modified bit.

Avi