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
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.
=============== Diff against MonticelloConfigurations-cmm.97 ===============
Item was changed: ----- Method: MCConfigurationBrowser>>checkDependencies (in category 'dependencies') ----- checkDependencies
- ^self checkModified and: [self checkMissing]!
- | missing |
- missing := (self dependencies collect:
- [ : ea | ea versionInfo name ]) asSet.
- self repositories do:
- [ : eachRepository | eachRepository cacheAllFileNamesDuring:
- [ missing copy do:
- [ : eachVersionName | (eachRepository includesVersionNamed: eachVersionName) ifTrue: [ missing remove: eachVersionName ] ] ] ].
- ^ missing isEmpty or:
- [ self selectDependency: missing anyOne.
- self confirm:
- (String streamContents:
- [ : strm | strm
- nextPutAll: 'No repository found for' ;
- cr.
- missing do:
- [ : r | strm
- nextPutAll: r ;
- cr ].
- strm nextPutAll: 'Do you still want to store?' ]) ]!
Item was added:
- ----- Method: MCConfigurationBrowser>>checkMissing (in category 'dependencies') -----
- checkMissing
- | missing |
- missing := (self dependencies collect:
- [ : ea | ea versionInfo name ]) asSet.
- self repositories do:
- [ : eachRepository | eachRepository cacheAllFileNamesDuring:
- [ missing copy do:
- [ : eachVersionName | (eachRepository includesVersionNamed: eachVersionName) ifTrue: [ missing remove: eachVersionName ] ] ] ].
- ^ missing isEmpty or:
- [ self selectDependency: missing anyOne.
- self confirm:
- (String streamContents:
- [ : strm | strm
- nextPutAll: 'No repository found for' ;
- cr.
- missing do:
- [ : r | strm
- nextPutAll: r ;
- cr ].
- strm nextPutAll: 'Do you still want to store?' ]) ]!
Item was changed: ----- Method: MCConfigurationBrowser>>store (in category 'actions') ----- store
- (self checkRepositories and: [self checkDependencies]) ifFalse: [^self].
- self pickName ifNotNil: [:name |
- self configuration name: name.
- self pickRepository ifNotNil: [:repo |
- repo storeVersion: self configuration]].!
- (self checkRepositories and: [ self checkDependencies ]) ifFalse: [ ^ self ].
- self pickName ifNotNil:
- [ : name | self configuration name: name.
- self pickRepository ifNotNil:
- [ : repo | repo cacheAllFileNamesDuring:
- [ self configuration dependencies do:
- [ : each | repo
- versionWithInfo: each versionInfo
- ifAbsent: [ repo storeVersion: (MCRepositoryGroup default versionWithInfo: each versionInfo) ] ] ].
- repo storeVersion: self configuration ] ]!
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
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 -
squeak-dev@lists.squeakfoundation.org