On 23.08.2011, at 04:27, David T. Lewis wrote:

> On Mon, Aug 22, 2011 at 08:39:33PM -0500, Chris Muller wrote:
>> 
>> On Sun, Aug 21, 2011 at 12:23 PM,  <commits at source.squeak.org> wrote:
>>> 
>>> David T. Lewis uploaded a new version of MonticelloConfigurations to project The Trunk:
>>> http://source.squeak.org/trunk/MonticelloConfigurations-dtl.98.mcz
>>> 
>>> ==================== Summary ====================
>>> 
>>> Name: MonticelloConfigurations-dtl.98
>>> Author: dtl
>>> Time: 21 August 2011, 1:23:49.864 pm
>>> UUID: 0a3ef28c-0cbb-4dd2-9a08-3923a305d67e
>>> Ancestors: MonticelloConfigurations-cmm.97
>>> 
>>> A configuration should not copy files into a target repository without knowledge or permission of the user. Revert prior changes until a safer implementation is proposed.
>> 
>> My goal is to make it easy for Squeak users to store working configurations.
>> 
>> Berts comment finally clued me in about why MCConfigurations have
>> multiple repository's and then, on top of that, prompting the user for
>> yet another repository.  The ones that are part of the Config specify
>> where to access the packages.  The one prompted by the menu is asking
>> for where to store the .mcm itself.  This is to support configurations
>> that source from a variety of repositories.
>> 
>> Bert said he was ok with the smart-copy with a warning guard, how
>> about you?  Friends, I am sincerely curious why we would want to store
>> a broken configuration.  The Config specifies the packages that will
>> be copied, and "permission" is indicated by the user clicking the
>> "Store" button (the balloon help for it says, "Store the
>> Configuration").  It seems obvious and "safe" to me.  I don't even
>> think we need the warning, but I would certainly rather live with that
>> than continuing to copy packages individually..
>> 
>> - Chris
> 
> I think we are dealing with two different use cases. IIUC, you are
> trying to make it simpler and more intuitive to copy the files
> referenced by a configuration into some repository, which would
> then contain some coherent snapshot of that configuration in the
> target repository.
> 
> I am expecting exactly the opposite for use in an update stream,
> with the configuration specifying the location of the real
> repository for each package of interest, and the files remaining
> in their home repositories under the control of their respective
> package maintainers.
> 
> To me, the configuration is a declaration that describes how to
> locate the files of interest. If I save the configuration, I
> am expecting to save that configuration description, but I
> am not expecting to take any action that affects the files
> themselves.
> 
> If copying files to a target repository is a useful thing to
> do, then this function probably deserves its own button on the
> browser along with a help balloon to explain what it is doing.
> This also implies that a MCConfigurationBrowser knows its
> "home" repository (presumably just the first one in its list
> of repositories). That is not visually apparent to the user
> looking at the browser, so any function that copies files
> to a target respository needs to make it very clear what is
> being copied, and to what repository the files are being added.
> 
> Note also that when saving a configuration, there is no notion
> of a default repository for that configuration. Instead, the
> user is prompted to select a repository in which to save the
> configuration. Thus, with the current UI, there is no natural
> notion of a default repository to which files might be copied,
> and thus no expectation on the part of the user that there is
> any repository that would be updated as a result of saving the
> configuration.
> 
> Dave

Exactly.

- Bert -