Avi

I do not know but improving the bubbles is really required.
:)

Stef

On 19 sept. 05, at 01:27, Avi Bryant wrote:

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