[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squeak-dev
Subject:    Re: [squeak-dev] The Trunk: MonticelloConfigurations-dtl.98.mcz
From:       Bert Freudenberg <bert () freudenbergs ! de>
Date:       2011-08-23 8:44:14
Message-ID: C54EF3C0-77F0-4BEC-BD7E-7615CEBBA387 () freudenbergs ! de
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]