Publishing on Monticello
stéphane ducasse
ducasse at iam.unibe.ch
Mon Sep 19 06:49:39 UTC 2005
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
>
>
More information about the Squeak-dev
mailing list
|