Am 19.09.2005 um 02:00 schrieb Avi Bryant:

> On Sep 18, 2005, at 4:27 PM, Avi Bryant wrote:
>
>> 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.
>>
>
> Thinking about this slightly more: it's not really about the  
> modified flag, because the local changes may have been saved/ 
> committed somewhere already.  The deciding factor is not just  
> whether the package is currently dirty, but whether the working  
> copy is an unmodified ancestor of the version you're updating to.   
> This makes it an even harder choice for the users to make unaided.

... sounds very much like the intended "upgrade" semantics of  
MCConfigurations :)

I like the idea of the "Upgrade" (preserve local changes) and  
"Replace" (discard local changes) buttons, though I'd still like a  
better term for "replace".

- Bert -