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