First, an easy one...I'd like the ability to browse the code of certain packages on SqueakMap (could just do the easy ones like change sets and *.st packages first)...it would be a little more difficult for SARs, but shouldn't be impossible.
Now for a more elaborate request involving SqueakMap and Monticello...what I would like in Monticello is the ability to assign a version string to a package (but still have the auto-generated version numbers). Then I'd like the ability to directly export a package version to another repository. And, I possibly might want to be able to organize repositories in a hierachical fashion and have a "promote" capability that would simply export a package version to the "parent repository" in the hierarchy. The version string would enable me to correlate versions in multiple repositories (since the internal version number would not match up). Package versions would have to have a version string before they are allowed to be exported. Once a package has been exported to another repository, its version string would become immutable (in both repositories).
Then, I'd like SqueakMap to be able to register a package that resides in a Monticello repository and have SqueakMap (server or client, whichever works best) be able to communicate with the repository to pull version information, etc for the package.
This of course then implies that there needs to be some measure of security in Monticello that would allow read-only access but restrict update access.
Why do I want these things?
So that I can have a local repository on my laptop for my packages, have a shared private repository for projects that I'm working on with other people, and have a public respository for published projects accessible through SqueakMap.
As I work, I'll create versions in my local repository. I'll occassionally publish versions to the shared repository, and when ready, I'll finally push versions out to the public repository.
Perhaps a simply hierarchy of repositories would not be sufficient...instead, I might want to simply be able to "link" repositories (and name the repositories) and be able to "push" packages between them. The linking would serve no other purpose than to make it simple to "right click a package version, and 'push' it to one of a list of linked repositories".
- Stephen
I'd like to follow up on a post from 11/21/2002. Stephen's requests match some things I'd like to do with SqueakMap and Monticello. I'm reposting his message because I never saw any followup on it.
Stephen Pair wrote:
First, an easy one...I'd like the ability to browse the code of certain packages on SqueakMap (could just do the easy ones like change sets and *.st packages first)...it would be a little more difficult for SARs, but shouldn't be impossible.
Now for a more elaborate request involving SqueakMap and Monticello...what I would like in Monticello is the ability to assign a version string to a package (but still have the auto-generated version numbers). Then I'd like the ability to directly export a package version to another repository. And, I possibly might want to be able to organize repositories in a hierachical fashion and have a "promote" capability that would simply export a package version to the "parent repository" in the hierarchy. The version string would enable me to correlate versions in multiple repositories (since the internal version number would not match up). Package versions would have to have a version string before they are allowed to be exported. Once a package has been exported to another repository, its version string would become immutable (in both repositories).
Then, I'd like SqueakMap to be able to register a package that resides in a Monticello repository and have SqueakMap (server or client, whichever works best) be able to communicate with the repository to pull version information, etc for the package.
This of course then implies that there needs to be some measure of security in Monticello that would allow read-only access but restrict update access.
Why do I want these things?
So that I can have a local repository on my laptop for my packages, have a shared private repository for projects that I'm working on with other people, and have a public respository for published projects accessible through SqueakMap.
As I work, I'll create versions in my local repository. I'll occassionally publish versions to the shared repository, and when ready, I'll finally push versions out to the public repository.
Perhaps a simply hierarchy of repositories would not be sufficient...instead, I might want to simply be able to "link" repositories (and name the repositories) and be able to "push" packages between them. The linking would serve no other purpose than to make it simple to "right click a package version, and 'push' it to one of a list of linked repositories".
- Stephen
I'd like to be able to pull all the packages from SqueakMap I need into my local repository so that I can track changes the authors make as well as changes I may need for my application.
In addition to these items, I'm wondering how to handle grouping of packages into larger entities, such as "all the packages I need for this application I'm building." I'm not sure if Monticello yet has this concept for a set of packages or set of versions of packages.
It's in some ways related to the loadscripts talked about in the SqueakMap context but loading from Monticello repositories.
I'm wondering, what is the Monticello equivalent for something like Envy Configuration Maps or Store Bundles?
-Mark
On Thursday 18 September 2003 06:10 pm, Mark A. Schwenk wrote:
In addition to these items, I'm wondering how to handle grouping of packages into larger entities, such as "all the packages I need for this application I'm building." I'm not sure if Monticello yet has this concept for a set of packages or set of versions of packages.
It's in some ways related to the loadscripts talked about in the SqueakMap context but loading from Monticello repositories.
I'm wondering, what is the Monticello equivalent for something like Envy Configuration Maps or Store Bundles?
It's a SAR with all the .mcv packages inside.
I suppose I should publish the latest SARBuilder if I haven't already.
Ned Konz wrote:
On Thursday 18 September 2003 06:10 pm, Mark A. Schwenk wrote:
In addition to these items, I'm wondering how to handle grouping of packages into larger entities, such as "all the packages I need for this application I'm building." I'm not sure if Monticello yet has this concept for a set of packages or set of versions of packages.
It's in some ways related to the loadscripts talked about in the SqueakMap context but loading from Monticello repositories.
I'm wondering, what is the Monticello equivalent for something like Envy Configuration Maps or Store Bundles?
It's a SAR with all the .mcv packages inside.
And what about those packages that aren't available as .mcz files yet? What do you think about adding support for SARs with SARs as members?
-Mark
Ned Konz wrote:
On Thursday 18 September 2003 06:10 pm, Mark A. Schwenk wrote:
In addition to these items, I'm wondering how to handle grouping of packages into larger entities, such as "all the packages I need for this application I'm building." I'm not sure if Monticello yet has this concept for a set of packages or set of versions of packages.
It's in some ways related to the loadscripts talked about in the SqueakMap context but loading from Monticello repositories.
I'm wondering, what is the Monticello equivalent for something like Envy Configuration Maps or Store Bundles?
It's a SAR with all the .mcv packages inside.
It appears that SARinstaller wants to laod MonticelloCVS to deal with the .mcz members, even though that package should not be required now.
If I let SARInstaller load MonticelloCVS, it eventually blows up because it does not seem to understand that the .mcz files are zip files.
-Mark
On Sunday 21 September 2003 11:50 pm, Mark A. Schwenk wrote:
Ned Konz wrote:
On Thursday 18 September 2003 06:10 pm, Mark A. Schwenk wrote:
In addition to these items, I'm wondering how to handle grouping of packages into larger entities, such as "all the packages I need for this application I'm building." I'm not sure if Monticello yet has this concept for a set of packages or set of versions of packages.
It's in some ways related to the loadscripts talked about in the SqueakMap context but loading from Monticello repositories.
I'm wondering, what is the Monticello equivalent for something like Envy Configuration Maps or Store Bundles?
It's a SAR with all the .mcv packages inside.
It appears that SARinstaller wants to laod MonticelloCVS to deal with the .mcz members, even though that package should not be required now.
Which SARInstaller version do you have? I recently posted a fix CS.
If I let SARInstaller load MonticelloCVS, it eventually blows up because it does not seem to understand that the .mcz files are zip files.
What do you mean?
What blows up?
What .mcz files? I was referring to a SAR with .mcv files (SAR files can't currently handle .mcz files).
Ned Konz wrote:
On Sunday 21 September 2003 11:50 pm, Mark A. Schwenk wrote:
Ned Konz wrote:
On Thursday 18 September 2003 06:10 pm, Mark A. Schwenk wrote:
In addition to these items, I'm wondering how to handle grouping of packages into larger entities, such as "all the packages I need for this application I'm building." I'm not sure if Monticello yet has this concept for a set of packages or set of versions of packages.
It's in some ways related to the loadscripts talked about in the SqueakMap context but loading from Monticello repositories.
I'm wondering, what is the Monticello equivalent for something like Envy Configuration Maps or Store Bundles?
It's a SAR with all the .mcv packages inside.
It appears that SARinstaller wants to laod MonticelloCVS to deal with the .mcz members, even though that package should not be required now.
Which SARInstaller version do you have? I recently posted a fix CS.
I was using the SqueakMap version for 3.6:
SARInstaller for 3.6 (18)
I thought that version would be the most up-to-date. I didn't have the fixes loaded. Is it because the package is part of the 3.6 image that you can't update the SqueakMap package to include the latest fixes?
If I let SARInstaller load MonticelloCVS, it eventually blows up because it does not seem to understand that the .mcz files are zip files.
What do you mean?
What blows up?
What .mcz files? I was referring to a SAR with .mcv files (SAR files can't currently handle .mcz files).
The current version of Monticello seems to write .mcz files, not .mcv files. What I meant was that SARInstaller, as you stated, doesn't properly handle .mcz files.
Thanks for your help! -Mark
On Monday 22 September 2003 10:36 am, Mark A. Schwenk wrote:
Which SARInstaller version do you have? I recently posted a fix CS.
I was using the SqueakMap version for 3.6:
SARInstaller for 3.6 (18)
I thought that version would be the most up-to-date. I didn't have the fixes loaded. Is it because the package is part of the 3.6 image that you can't update the SqueakMap package to include the latest fixes?
You could if I had updated it on SqueakMap, which I haven't gotten around to doing, yet.
The current version of Monticello seems to write .mcz files, not .mcv files. What I meant was that SARInstaller, as you stated, doesn't properly handle .mcz files.
The latest version of SARBuilder will put .mcv files into a SAR.
On Thu, 18 Sep 2003, Mark A. Schwenk wrote:
I'd like to be able to pull all the packages from SqueakMap I need into my local repository so that I can track changes the authors make as well as changes I may need for my application.
Assuming we're talking about Monticello packages, there's no problem with this. When you make local modifications, just save those modified packages locally. When the author releases a new version, you can merge it in. Because the ancestry tree is stored with each version, and not per-repository, it's just as easy to merge code from separate repositories as it would be if all the versions were kept centrally.
Monticello also doesn't have the "multiple-merge" problem that CVS exhibits - you can merge the mainline into your branch as many times as you like without having to deal with spurious conflicts.
In addition to these items, I'm wondering how to handle grouping of packages into larger entities, such as "all the packages I need for this application I'm building." I'm not sure if Monticello yet has this concept for a set of packages or set of versions of packages.
It doesn't. As Ned points out, SARs are one way of managing this externally to Monticello. I'd also like to introduce some kind of notion of tagging (so you could have a tag "MyApp-v2" that would refer to all the package versions that made up that app version), but don't have a clear design in mind yet. Suggestions are welcome.
Avi
Avi Bryant wrote:
On Thu, 18 Sep 2003, Mark A. Schwenk wrote:
In addition to these items, I'm wondering how to handle grouping of packages into larger entities, such as "all the packages I need for this application I'm building." I'm not sure if Monticello yet has this concept for a set of packages or set of versions of packages.
It doesn't. As Ned points out, SARs are one way of managing this externally to Monticello. I'd also like to introduce some kind of notion of tagging (so you could have a tag "MyApp-v2" that would refer to all the package versions that made up that app version), but don't have a clear design in mind yet. Suggestions are welcome.
Avi
How about doing this with a Bundle version named "MyApp-v2" where a Bundle version is an ordered collection of references to Monticello Package versions and Bundle versions?
-Mark
On Thursday, September 18, 2003, at 06:10 PM, Mark A. Schwenk wrote:
I'd like to follow up on a post from 11/21/2002. Stephen's requests match some things I'd like to do with SqueakMap and Monticello. I'm reposting his message because I never saw any followup on it.
[Stephen's post snipped]
Wow, it's hard to believe Monticello is nearly a year old. The gist of Stephen's request was that he wanted to be able to define a hierarchy of repositories and have facilities for moving versions of packages up and down the hierarchy.
We haven't implemented anything like that, basically because it turned out to be unnecessary. We do support multiple repositories, so it's not hard to accomplish the hierarchical scenario, if that's what you want, or other combinations of local/remote, public/private respositories.
Neither have we done any specific integration with SqueakMap, but we *have* put a lot of work into making Monticello's internal file format suitable for distributing packages. So a package's SqueakMap entry can include a link directly to a specific version in a repository. There might be useful opportunities for tighter integration when SqueakMap2 is finished.
I'd like to be able to pull all the packages from SqueakMap I need into my local repository so that I can track changes the authors make as well as changes I may need for my application.
You can do this today, provided that the package author is also using Monticello, and distributes his packages in mcz format. When you install such a package, Monticello will create a working copy for it. As you make changes you can save them as versions in your own repository, and merge in versions published by the author as necessary.
In addition to these items, I'm wondering how to handle grouping of packages into larger entities, such as "all the packages I need for this application I'm building." I'm not sure if Monticello yet has this concept for a set of packages or set of versions of packages.
It's in some ways related to the loadscripts talked about in the SqueakMap context but loading from Monticello repositories.
No, right now there's no way to group packages in Monticello. It's probably something we'll need at some point, but right now I feel like we don't have enough experience using Monticello to know how exactly it should work. Maybe SqueakMap2 will help with this. If you have any thoughts, please share them.
I'm wondering, what is the Monticello equivalent for something like Envy Configuration Maps or Store Bundles?
As Ned mentioned, you can stick mcz files into a sar for distribution. But Monticello doesn't know how to operate on groups of packages.
Colin
Colin Putney cputney@wiresong.ca wrote: [SNIP]
It's in some ways related to the loadscripts talked about in the SqueakMap context but loading from Monticello repositories.
No, right now there's no way to group packages in Monticello. It's probably something we'll need at some point, but right now I feel like we don't have enough experience using Monticello to know how exactly it should work. Maybe SqueakMap2 will help with this. If you have any thoughts, please share them.
Yes, SM2 will make the picture very different. First of all it contains a proper file package cache. Then it also keeps track of package *releases*. And finally it has the ability to associate "meta data" to the package releases (and to other things too in fact).
One obvious (and planned) use for the metadata facility is to associate what I have called "package configurations" to package releases. That would then evolve to a full dependency system. *But*... that is not included in SM - that is a *separate* system.
I'm wondering, what is the Monticello equivalent for something like Envy Configuration Maps or Store Bundles?
As Ned mentioned, you can stick mcz files into a sar for distribution. But Monticello doesn't know how to operate on groups of packages.
Colin
And hopefully (at least I hope that) dependencies etc are more properly taken care of in the SM context. One obvious reason is that Monticello is just *one* format for packages. Dependencies should be handled generically for all formats IMHO.
regards, Göran
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
Colin Putney -
goran.krampe＠bluefish.se -
Mark A. Schwenk -
Ned Konz -
Stephen Pair