It's all here:
http://wiki.squeak.org/squeak/6365 http://wiki.squeak.org/squeak/6365
This is what source.squeak.org is running. It installs and runs clean (in Linux). It never saves the running image.
Every serious Squeak developer should do it on their laptop, so they can have the revision history for their own proprietary code, not just the source.squeak.org repositories.
This is interesting, but it seems over engineered. Http was never part of the first, second or third designs of Monticello. It went large when people in Bern made SqueakSource. The aim, I think, was to present the packages in an HTML format for people to read instead of having a faceless HTTP address access to a file directory somewhere. After that, it seems, people forgot Monticello has ten different kinds of repository available.
With the instructions I’ve shown below, I think a person could do what you’re doing after five minutes of setup using only Monticello in an any image. [1] And it would work on any OS, not just Linux. Getting Installer scripts to point to a directory on your desktop (simultaneously copying into Dropbox perhaps?) would be a next and probably simple step.
All the code history is in the MC files on disk. I don’t think SqueakSource has anything to say about your versions. I don’t think you need SqueakSource at all. Just Monticello. Is there something here I’m missing?
Chris
[1] 1 Create a desktop folder called “MyMonticelloFiles” 2 In MC add as a directory repository pointing to MyMonticelloFiles 3 Existing packages in MC won’t see the new repo from “add repository”, until… 4 Go to Browser. Put any class in a new class category (i.e. MCDummyCategory) 5 Add new package “MCDummyCategory” in MC 6 “Add Repository” for MCDummyCategory to MyMonticelloFiles repository 7 Save MCDummyCategory to MyMonticelloFiles on disk 8 All existing packages now have MyMonticelloFiles as a destination 9 Adapt Installer script to use “Installer monticello directory: ‘MyMonticelloFiles’ or something Details here, I suppose. http://installer.pbworks.com/w/page/19997682/Installer
To try to answer the "what am I missing" part of the question:
Chris Muller is explaining how you can set up your own local server that works exactly like the one on source.squeak.org. For example, if someone wanted to work on improving the responsiveness of updates on source.squeak.org, they could follow Chris' instructions to set up their own private squeaksource which they could use and modify without affecting the production source.squeak.org server.
I think that Chris would also be happy if a few more of us tried following his instructions so that we would have a better understanding of how the system works.
Dave
It's all here:
http://wiki.squeak.org/squeak/6365 http://wiki.squeak.org/squeak/6365
This is what source.squeak.org is running. It installs and runs clean (in Linux). It never saves the running image.
Every serious Squeak developer should do it on their laptop, so they can have the revision history for their own proprietary code, not just the source.squeak.org repositories.
This is interesting, but it seems over engineered. Http was never part of the first, second or third designs of Monticello. It went large when people in Bern made SqueakSource. The aim, I think, was to present the packages in an HTML format for people to read instead of having a faceless HTTP address access to a file directory somewhere. After that, it seems, people forgot Monticello has ten different kinds of repository available.
With the instructions Iâve shown below, I think a person could do what youâre doing after five minutes of setup using only Monticello in an any image. [1] And it would work on any OS, not just Linux. Getting Installer scripts to point to a directory on your desktop (simultaneously copying into Dropbox perhaps?) would be a next and probably simple step.
All the code history is in the MC files on disk. I donât think SqueakSource has anything to say about your versions. I donât think you need SqueakSource at all. Just Monticello. Is there something here Iâm missing?
Chris
[1] 1 Create a desktop folder called âMyMonticelloFilesâ 2 In MC add as a directory repository pointing to MyMonticelloFiles 3 Existing packages in MC wonât see the new repo from âadd repositoryâ, until⦠4 Go to Browser. Put any class in a new class category (i.e. MCDummyCategory) 5 Add new package âMCDummyCategoryâ in MC 6 âAdd Repositoryâ for MCDummyCategory to MyMonticelloFiles repository 7 Save MCDummyCategory to MyMonticelloFiles on disk 8 All existing packages now have MyMonticelloFiles as a destination 9 Adapt Installer script to use âInstaller monticello directory: âMyMonticelloFilesâ or something Details here, I suppose. http://installer.pbworks.com/w/page/19997682/Installer
A slightly off-the-wall approach might be to have the submitting machine create the diff and send it along with the main package. The server is relieved of having to worry about it at a probably small cost in network usage.
Another option - don’t send the whole diff out by email; save it to somewhere that has a stable URL and put that in the email.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RIW: Re-Invent Wheel
On Wed, Jan 24, 2018 at 12:39 PM, tim Rowledge tim@rowledge.org wrote:
A slightly off-the-wall approach might be to have the submitting machine create the diff and send it along with the main package. The server is relieved of having to worry about it at a probably small cost in network usage.
Another option - don’t send the whole diff out by email; save it to somewhere that has a stable URL and put that in the email.
Those aren't either/or options.
Maybe a 'short' diff (256 characters, say) of the full diff is sent out, with a link to the full diff back on the server. Small changes are included in the email; large changes need to use a browser.
Additionally, either the submitter does the diff, or a background does the diff, or something even smarter that someone finally thinks of.
-cbc
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RIW: Re-Invent Wheel
Hi all,
On 24.01.2018, at 21:52, Chris Cunningham cunningham.cb@gmail.com wrote:
On Wed, Jan 24, 2018 at 12:39 PM, tim Rowledge tim@rowledge.org wrote: A slightly off-the-wall approach might be to have the submitting machine create the diff and send it along with the main package. The server is relieved of having to worry about it at a probably small cost in network usage.
Another option - don’t send the whole diff out by email; save it to somewhere that has a stable URL and put that in the email.
Those aren't either/or options.
Maybe a 'short' diff (256 characters, say) of the full diff is sent out, with a link to the full diff back on the server. Small changes are included in the email; large changes need to use a browser.
Additionally, either the submitter does the diff, or a background does the diff, or something even smarter that someone finally thinks of.
We already have a cuttoff for excessive size, maybe tune it down?
On another note, for squeaksource3 I had actually implemented such a thing. First, there are different "subscriptions" for such actions (version upload) These subscriptions include - mail sending but could include - Cache invalidation (I have the page cached that monticello downloads) - statistics update .
Those are handled asynchrony by a different Process (in Squeak) or a dedicated service VM (in GemStone)
See here: http://www.squeaksource.com/squeaksource3.html package SqueakSource-Subscription-Core-topa.12.mcz SqueakSource-Subscription-Email-topa.13.mcz (plus platformspecific: SqueakSource-SqueakPharo-Subscription-Core-topa.8.mcz (extra process)
Hope that helps. -Tobias
squeak-dev@lists.squeakfoundation.org
-
Chris Cunningham -
Chris Cunnington -
David T. Lewis -
tim Rowledge -
Tobias Pape