[Pharo-project] Not a disaster (this time)
Hello all, I am trying to be a good tester, and have been shot in the foot now for a couple of days. That's no great loss, but a similar set of circumstances could be very ugly in the future. My ailing build process for RC1 is thwarted by source.squeakfoundation.org's being offline. Imagine a deadline (paying customer, mission-critical gizmo, grant submission - whatever haunts you) and being stuck. I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server. Having chosen the package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but apparently that's not what it does. There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. There isn't (at least not that I can find), and it does :( Bill
There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. Â There isn't (at least not that I can find), and it does :(
Parse error. Monticello is a distributed versioning system, so it is highly redundant by definition. You can't really blame anybody else if a version your are interested in is not reachable. I usually copy important code into my local repository. http://en.wikipedia.org/wiki/Revision_control#Distributed_revision_control Lukas -- Lukas Renggli http://www.lukas-renggli.ch
2009/11/9 Lukas Renggli <renggli@gmail.com>:
There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. Â There isn't (at least not that I can find), and it does :(
Parse error.
Monticello is a distributed versioning system, so it is highly redundant by definition. You can't really blame anybody else if a version your are interested in is not reachable. I usually copy important code into my local repository.
  http://en.wikipedia.org/wiki/Revision_control#Distributed_revision_control
If i understanding the problem clearly, MC checks the current contents of all repositories, defined for package, before saving a package, even locally. So, if one of repositories can't be reached, this leads to error and unability to save a local copy on hard drive. I think that this check can be reduced to check/refresh the contents of repository where user wants to save the package, but not all of them. Correct me, if i wrong.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
If i understanding the problem clearly, MC checks the current contents of all repositories, defined for package, before saving a package, even locally.
No. Monticello saves into the selected repository and into the local package-cache only. This is the same as you get with Git (and other similar distributed versioning systems), when you do a "git commit" and "git push <repository>" .
So, if one of repositories can't be reached, this leads to error and unability to save a local copy on hard drive.
Monticello only loads from a selected repository, it does not try multiple repositories. It could lead to different results depending on from what repository you load. Again that is the same same as with "git pull <repository>". Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
2009/11/9 Lukas Renggli <renggli@gmail.com>:
If i understanding the problem clearly, MC checks the current contents of all repositories, defined for package, before saving a package, even locally.
No. Monticello saves into the selected repository and into the local package-cache only. This is the same as you get with Git (and other similar distributed versioning systems), when you do a "git commit" and "git push <repository>" .
Then how do you comment this:
I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server. Having chosen the >package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but >apparently that's not what it does.
So, if one of repositories can't be reached, this leads to error and unability to save a local copy on hard drive.
Monticello only loads from a selected repository, it does not try multiple repositories. It could lead to different results depending on from what repository you load. Again that is the same same as with "git pull <repository>".
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Lukas, The whole server is down, and MC (at least out of the box and with some help from ScriptLoader) comes uglued over it. I don't blame the servers; I *do* blame the design. Adrian seems to have the defects and the workaround in mind. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Monday, November 09, 2009 2:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time)
There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. Â There isn't (at least not that I can find), and it does :(
Parse error. Monticello is a distributed versioning system, so it is highly redundant by definition. You can't really blame anybody else if a version your are interested in is not reachable. I usually copy important code into my local repository. http://en.wikipedia.org/wiki/Revision_control#Distributed_revision_control Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Lukas Renggli wrote:
There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. There isn't (at least not that I can find), and it does :(
Parse error.
Monticello is a distributed versioning system, so it is highly redundant by definition. You can't really blame anybody else if a version your are interested in is not reachable. I usually copy important code into my local repository.
Well, on the other hand it is extremely bad publicity if the Squeak community's main source repository, written in Squeak, is extremely unreliable. How can one expect someone to switch to Squeak when the first thing is encountering it being unreliable? Michael
Michael, Good point. Without starting a flame war, I find it necessary to give a big +1 to Pharo (the system and the people behind it) - I doubt I would be this far along in a move to Squeak. Servers quit (especially Windows boxes<g>), routers fail, and ISPs have bad days. The external world is not always visible. There is clearly a part of MC that does not anticipate these problems, and there need to be workarounds. It sounds like others have found them; I might build it into a future version of Migrate. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Monday, November 09, 2009 2:57 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time) Lukas Renggli wrote:
There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. There isn't (at least not that I can find), and it does :(
Parse error.
Monticello is a distributed versioning system, so it is highly redundant by definition. You can't really blame anybody else if a version your are interested in is not reachable. I usually copy important code into my local repository.
Well, on the other hand it is extremely bad publicity if the Squeak community's main source repository, written in Squeak, is extremely unreliable. How can one expect someone to switch to Squeak when the first thing is encountering it being unreliable? Michael _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Monticello is a distributed versioning system, so it is highly redundant by definition. You can't really blame anybody else if a version your are interested in is not reachable. I usually copy important code into my local repository.
Well, on the other hand it is extremely bad publicity if the Squeak community's main source repository, written in Squeak, is extremely unreliable. How can one expect someone to switch to Squeak when the first thing is encountering it being unreliable?
I don't know what is hosted on source.squeakfoundation.org and who is maintaining it. www.squeaksource.com has been running pretty stable over the last few years and silently serving its 7.5+ GB of Monticello versions. Feel free to setup your own server, using your own hardware, bandwidth and time; it is a distributed versioning system after all. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli wrote:
I don't know what is hosted on source.squeakfoundation.org and who is maintaining it.
You are not quite getting the point. As long as Pharo relies on *anything* hosted on unreliable servers hosted by anyone the bad PR falls back on the Pharo community. And if I would look at scripting language XY and something doesn't work and the answer I get is "oh, just install your own server, it's all distributed, stupid, don't rely on the offical servers, ..." What do you think my reaction will be? Michael
I don't know what is hosted on source.squeakfoundation.org and who is maintaining it.
You are not quite getting the point. As long as Pharo relies on *anything* hosted on unreliable servers hosted by anyone the bad PR falls back on the Pharo community.
You are also not getting the point. Why would Pharo rely on source.squeakfoundation.org? Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Michael, Please hold that thought on marketing. In fairness, the problem is not so much that Pharo relies on an unreliable server (which might not even be the case - being down "now" and being down a lot are two different things) as it is that the package management tools (at least as far as I have seen) are lacking important features. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Monday, November 09, 2009 6:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time) Lukas Renggli wrote:
I don't know what is hosted on source.squeakfoundation.org and who is maintaining it.
You are not quite getting the point. As long as Pharo relies on *anything* hosted on unreliable servers hosted by anyone the bad PR falls back on the Pharo community. And if I would look at scripting language XY and something doesn't work and the answer I get is "oh, just install your own server, it's all distributed, stupid, don't rely on the offical servers, ..." What do you think my reaction will be? Michael _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
If you don't follow the squeak list, then you won't know they install the patches from 2007 to fix the problem, although there are some thoughts now what about patches from later in 2007 & 2008? Hopefully this kicks off some reflection in their infrastructure support teams about why some patches are deemed highly critical for squeak based server images. On 2009-11-09, at 4:00 PM, Schwab,Wilhelm K wrote:
Michael,
Please hold that thought on marketing. In fairness, the problem is not so much that Pharo relies on an unreliable server (which might not even be the case - being down "now" and being down a lot are two different things) as it is that the package management tools (at least as far as I have seen) are lacking important features.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo- project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Monday, November 09, 2009 6:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time)
Lukas Renggli wrote:
I don't know what is hosted on source.squeakfoundation.org and who is maintaining it.
You are not quite getting the point. As long as Pharo relies on *anything* hosted on unreliable servers hosted by anyone the bad PR falls back on the Pharo community.
And if I would look at scripting language XY and something doesn't work and the answer I get is "oh, just install your own server, it's all distributed, stupid, don't rely on the offical servers, ..." What do you think my reaction will be?
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Hi Bill, At netstyle.ch and Cmsbox we have the rule that all projects have to be completely loadable from our own MC repository. I suggest to do the same for the reasons you mention below. You never know what happens to external resources... Storing a local copy with MC should not be a problem. Actually, the package-cache folder should already contain the file. Cheers, Adrian On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote:
Hello all,
I am trying to be a good tester, and have been shot in the foot now for a couple of days. That's no great loss, but a similar set of circumstances could be very ugly in the future. My ailing build process for RC1 is thwarted by source.squeakfoundation.org's being offline. Imagine a deadline (paying customer, mission-critical gizmo, grant submission - whatever haunts you) and being stuck.
I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server. Having chosen the package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but apparently that's not what it does.
There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. There isn't (at least not that I can find), and it does :(
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian, You are correct, it does contain them (thanks for mentioning that). Saving my own copies _is_ a problem, but fortunately I do not need to do so. How do you enforce local loads? Do you insist on downloading everything yourselves, or do you have some type of lazy download with cancel capability? In an ideal world, I would hope to see a tool that tries to download the latest versions, shows progress toward same, and accepts user interaction to head off a hopeless situation like today. If the user cancels the download, then there would be an option to install from the local repository. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Monday, November 09, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time) Hi Bill, At netstyle.ch and Cmsbox we have the rule that all projects have to be completely loadable from our own MC repository. I suggest to do the same for the reasons you mention below. You never know what happens to external resources... Storing a local copy with MC should not be a problem. Actually, the package-cache folder should already contain the file. Cheers, Adrian On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote:
Hello all,
I am trying to be a good tester, and have been shot in the foot now for a couple of days. That's no great loss, but a similar set of circumstances could be very ugly in the future. My ailing build process for RC1 is thwarted by source.squeakfoundation.org's being offline. Imagine a deadline (paying customer, mission-critical gizmo, grant submission - whatever haunts you) and being stuck.
I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server. Having chosen the package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but apparently that's not what it does.
There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. There isn't (at least not that I can find), and it does :(
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
We don't have any automated approach. All images built load from our own repository. If a developer wants to add an external package or update an existing one, he has to save into our repository. Adrian On Nov 9, 2009, at 21:01 , Schwab,Wilhelm K wrote:
Adrian,
You are correct, it does contain them (thanks for mentioning that). Saving my own copies _is_ a problem, but fortunately I do not need to do so.
How do you enforce local loads? Do you insist on downloading everything yourselves, or do you have some type of lazy download with cancel capability? In an ideal world, I would hope to see a tool that tries to download the latest versions, shows progress toward same, and accepts user interaction to head off a hopeless situation like today. If the user cancels the download, then there would be an option to install from the local repository.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Adrian Lienhard Sent: Monday, November 09, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time)
Hi Bill,
At netstyle.ch and Cmsbox we have the rule that all projects have to be completely loadable from our own MC repository. I suggest to do the same for the reasons you mention below. You never know what happens to external resources...
Storing a local copy with MC should not be a problem. Actually, the package-cache folder should already contain the file.
Cheers, Adrian
On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote:
Hello all,
I am trying to be a good tester, and have been shot in the foot now for a couple of days. That's no great loss, but a similar set of circumstances could be very ugly in the future. My ailing build process for RC1 is thwarted by source.squeakfoundation.org's being offline. Imagine a deadline (paying customer, mission-critical gizmo, grant submission - whatever haunts you) and being stuck.
I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server. Having chosen the package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but apparently that's not what it does.
There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. There isn't (at least not that I can find), and it does :(
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Adrian, That's fine - it will certainly avoid the trap. Thanks! Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Monday, November 09, 2009 3:06 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time) We don't have any automated approach. All images built load from our own repository. If a developer wants to add an external package or update an existing one, he has to save into our repository. Adrian On Nov 9, 2009, at 21:01 , Schwab,Wilhelm K wrote:
Adrian,
You are correct, it does contain them (thanks for mentioning that). Saving my own copies _is_ a problem, but fortunately I do not need to do so.
How do you enforce local loads? Do you insist on downloading everything yourselves, or do you have some type of lazy download with cancel capability? In an ideal world, I would hope to see a tool that tries to download the latest versions, shows progress toward same, and accepts user interaction to head off a hopeless situation like today. If the user cancels the download, then there would be an option to install from the local repository.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Adrian Lienhard Sent: Monday, November 09, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time)
Hi Bill,
At netstyle.ch and Cmsbox we have the rule that all projects have to be completely loadable from our own MC repository. I suggest to do the same for the reasons you mention below. You never know what happens to external resources...
Storing a local copy with MC should not be a problem. Actually, the package-cache folder should already contain the file.
Cheers, Adrian
On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote:
Hello all,
I am trying to be a good tester, and have been shot in the foot now for a couple of days. That's no great loss, but a similar set of circumstances could be very ugly in the future. My ailing build process for RC1 is thwarted by source.squeakfoundation.org's being offline. Imagine a deadline (paying customer, mission-critical gizmo, grant submission - whatever haunts you) and being stuck.
I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server. Having chosen the package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but apparently that's not what it does.
There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. There isn't (at least not that I can find), and it does :(
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What I would like especially when coding in the train is that my script using a given repository can use my local cache. I know that Installer did not support that. Lukas is gofer supporting that behavior? Stef On Nov 9, 2009, at 9:06 PM, Adrian Lienhard wrote:
We don't have any automated approach. All images built load from our own repository. If a developer wants to add an external package or update an existing one, he has to save into our repository.
Adrian
On Nov 9, 2009, at 21:01 , Schwab,Wilhelm K wrote:
Adrian,
You are correct, it does contain them (thanks for mentioning that). Saving my own copies _is_ a problem, but fortunately I do not need to do so.
How do you enforce local loads? Do you insist on downloading everything yourselves, or do you have some type of lazy download with cancel capability? In an ideal world, I would hope to see a tool that tries to download the latest versions, shows progress toward same, and accepts user interaction to head off a hopeless situation like today. If the user cancels the download, then there would be an option to install from the local repository.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo- project-bounces@lists.gforge.inria.fr ] On Behalf Of Adrian Lienhard Sent: Monday, November 09, 2009 2:31 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time)
Hi Bill,
At netstyle.ch and Cmsbox we have the rule that all projects have to be completely loadable from our own MC repository. I suggest to do the same for the reasons you mention below. You never know what happens to external resources...
Storing a local copy with MC should not be a problem. Actually, the package-cache folder should already contain the file.
Cheers, Adrian
On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote:
Hello all,
I am trying to be a good tester, and have been shot in the foot now for a couple of days. That's no great loss, but a similar set of circumstances could be very ugly in the future. My ailing build process for RC1 is thwarted by source.squeakfoundation.org's being offline. Imagine a deadline (paying customer, mission-critical gizmo, grant submission - whatever haunts you) and being stuck.
I have even tried to save the FFI packages locally, and that seems to go haywire over talking to the server. Having chosen the package name and a local repository, I would expect MC to take the code it has locally and save it to my local drive, but apparently that's not what it does.
There is no need for urgent action (this is only a drill<g>), but there should be some redundancy in where the code is stored, and MC should not prevent my saving code I already have to my local drive. There isn't (at least not that I can find), and it does :(
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
As an FYI... for those using Metacello... In Metacello you can arrange to override the repositories used for loading ... useful in cases where servers are down or offline/not accessible for other reasons ...saves you from having to edit configurations ... I use the override for creating a repository from scratch (bootstrapping from a local disk-based repositories) when the configurations that I'm using reference the public HTTP repositories. Dale ----- "Wilhelm K Schwab" <bschwab@anest.ufl.edu> wrote: | Adrian, | | You are correct, it does contain them (thanks for mentioning that). | Saving my own copies _is_ a problem, but fortunately I do not need to | do so. | | How do you enforce local loads? Do you insist on downloading | everything yourselves, or do you have some type of lazy download with | cancel capability? In an ideal world, I would hope to see a tool that | tries to download the latest versions, shows progress toward same, and | accepts user interaction to head off a hopeless situation like today. | If the user cancels the download, then there would be an option to | install from the local repository. | | Bill | | | | -----Original Message----- | From: pharo-project-bounces@lists.gforge.inria.fr | [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of | Adrian Lienhard | Sent: Monday, November 09, 2009 2:31 PM | To: Pharo-project@lists.gforge.inria.fr | Subject: Re: [Pharo-project] Not a disaster (this time) | | Hi Bill, | | At netstyle.ch and Cmsbox we have the rule that all projects have to | be completely loadable from our own MC repository. I suggest to do the | same for the reasons you mention below. You never know what happens to | external resources... | | Storing a local copy with MC should not be a problem. Actually, the | package-cache folder should already contain the file. | | Cheers, | Adrian | | On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote: | | > Hello all, | > | > I am trying to be a good tester, and have been shot in the foot now | | > for a couple of days. That's no great loss, but a similar set of | > circumstances could be very ugly in the future. My ailing build | > process for RC1 is thwarted by source.squeakfoundation.org's being | > offline. Imagine a deadline (paying customer, mission-critical | gizmo, | > grant submission - whatever haunts you) and being stuck. | > | > I have even tried to save the FFI packages locally, and that seems | to | > go haywire over talking to the server. Having chosen the package | name | > and a local repository, I would expect MC to take the code it has | > locally and save it to my local drive, but apparently that's not | what | > it does. | > | > There is no need for urgent action (this is only a drill<g>), but | > there should be some redundancy in where the code is stored, and MC | > should not prevent my saving code I already have to my local drive. | | > There isn't (at least not that I can find), and it does :( | > | > Bill | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
That is a valuable feature. When/how does it make the decision that overrides are needed? Does it timeout and fail-over on each attempt? That could get painful to watch, or could be problematic on slow connections. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs Sent: Monday, November 09, 2009 3:26 PM To: Pharo-project@lists.gforge.inria.fr Cc: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Not a disaster (this time) As an FYI... for those using Metacello... In Metacello you can arrange to override the repositories used for loading ... useful in cases where servers are down or offline/not accessible for other reasons ...saves you from having to edit configurations ... I use the override for creating a repository from scratch (bootstrapping from a local disk-based repositories) when the configurations that I'm using reference the public HTTP repositories. Dale ----- "Wilhelm K Schwab" <bschwab@anest.ufl.edu> wrote: | Adrian, | | You are correct, it does contain them (thanks for mentioning that). | Saving my own copies _is_ a problem, but fortunately I do not need to | do so. | | How do you enforce local loads? Do you insist on downloading | everything yourselves, or do you have some type of lazy download with | cancel capability? In an ideal world, I would hope to see a tool that | tries to download the latest versions, shows progress toward same, and | accepts user interaction to head off a hopeless situation like today. | If the user cancels the download, then there would be an option to | install from the local repository. | | Bill | | | | -----Original Message----- | From: pharo-project-bounces@lists.gforge.inria.fr | [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of | Adrian Lienhard | Sent: Monday, November 09, 2009 2:31 PM | To: Pharo-project@lists.gforge.inria.fr | Subject: Re: [Pharo-project] Not a disaster (this time) | | Hi Bill, | | At netstyle.ch and Cmsbox we have the rule that all projects have to | be completely loadable from our own MC repository. I suggest to do the | same for the reasons you mention below. You never know what happens to | external resources... | | Storing a local copy with MC should not be a problem. Actually, the | package-cache folder should already contain the file. | | Cheers, | Adrian | | On Nov 9, 2009, at 19:54 , Schwab,Wilhelm K wrote: | | > Hello all, | > | > I am trying to be a good tester, and have been shot in the foot now | | > for a couple of days. That's no great loss, but a similar set of | > circumstances could be very ugly in the future. My ailing build | > process for RC1 is thwarted by source.squeakfoundation.org's being | > offline. Imagine a deadline (paying customer, mission-critical | gizmo, | > grant submission - whatever haunts you) and being stuck. | > | > I have even tried to save the FFI packages locally, and that seems | to | > go haywire over talking to the server. Having chosen the package | name | > and a local repository, I would expect MC to take the code it has | > locally and save it to my local drive, but apparently that's not | what | > it does. | > | > There is no need for urgent action (this is only a drill<g>), but | > there should be some redundancy in where the code is stored, and MC | > should not prevent my saving code I already have to my local drive. | | > There isn't (at least not that I can find), and it does :( | > | > Bill | > | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Adrian Lienhard -
Dale Henrichs -
Igor Stasenko -
John M McIntosh -
Lukas Renggli -
Michael Rueger -
Schwab,Wilhelm K -
Stéphane Ducasse