"Repository moved" hook
Locked
 
Administrator
|
Could we have such a hook?
The use case is that Magritte3 moved from lukas' server to StHub, creating a cascade of unknowingly out-of-date configurations - Magritte3AddOns, MagritteMagic, etc. As Magritte3 evolved, even loading the baseline of the downstream projects didn't help because it was pulling the pre-move #stable from the old repo. It would be ideal if there was a way to commit a final version of the config that when loaded would generate a proceed-able warning to the effect "Xyz Repository has moved to http://abc. Please change to get the latest code" Something where a configuration maintainer could e.g. 1. override say #repositoryMovedTo ^ 'http://abc' 2. wasRepositoryMoved ^ self repositoryMovedTo isNotNil What do you think?
Cheers,
Sean |
|
|
On Sunday, 26 April 2015 01:29:37 UTC+8, Sean DeNigris wrote: Could we have such a hook? This could be useful functionality, but it looks like its making the Metacello file executable, which I thought was discouraged. Also you are relying on write access to the old repo. Perhaps an additional or alternative way would be within the current Metacello file to be able to substitute repositories. That is, whenever repository A is referenced, use repository B -- or does something like this already exist? cheers -ben You received this message because you are subscribed to the Google Groups "Metacello" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
Administrator
|
True, this is in the specific case when the repo owner themselves wants to tag the move. IIRC this is possible with the scripting API, but Dale can confirm (or not:)). This is a separate feature, which could also be important, as an override for e.g. an abandoned repo. In the case I was dealing with, because the old repos were not tagged obsolete, I didn't even know they were, so wouldn't have known to override them.
Cheers,
Sean |
|
|
In reply to this post by Sean P. DeNigris
Sean,
Sorry for taking so long to respond ... I took time off (really off:) and then have been heads down on GemStone 3.3 work ... now that my work on GemStone 3.3 is wrapping up (not done yet:) I am tackling my email backlog ... I'm not quite sure that I understand the exact problem, so I can't tell what purpose a "repository moved" hook would serve. What exactly is out-of-date in Magritte3AddOns and/or MagritteMagic? My initial response is that old configurations should continue to work and that new configurations should be updated to point to the new things as needed and should also work. Dale On 4/25/15 10:15 AM, Sean P. DeNigris wrote: > Could we have such a hook? > > The use case is that Magritte3 moved from lukas' server to StHub, creating a > cascade of unknowingly out-of-date configurations - Magritte3AddOns, > MagritteMagic, etc. As Magritte3 evolved, even loading the baseline of the > downstream projects didn't help because it was pulling the pre-move #stable > from the old repo. > > It would be ideal if there was a way to commit a final version of the config > that when loaded would generate a proceed-able warning to the effect "Xyz > Repository has moved to http://abc. Please change to get the latest code" > > Something where a configuration maintainer could e.g. > 1. override say #repositoryMovedTo ^ 'http://abc' > 2. wasRepositoryMoved ^ self repositoryMovedTo isNotNil > > What do you think? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Repository-moved-hook-tp4821832.html > Sent from the Metacello mailing list archive at Nabble.com. > -- You received this message because you are subscribed to the Google Groups "Metacello" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
Administrator
|
NP. Glad you're back :) The problem is that, when a repository is moved, there is no programmatic way to know about it. So other configs that depend on it will keep happily loading from the old repo. What I'm proposing is a hook e.g. #repositoryMovedToURL so that a final config can be be committed in the old repo with this hook, and upon being loaded will signal a resumable exception telling that you are loading from an old repository and to where the config has been moved.
Cheers,
Sean |
|
|
I guess I'm still pretty dense ... repositories aren't moved so I'm not
sure what you mean ... If a new repository is being used then the configurations that are carried forward in the new repository should be edited to refer to the new repository ... I think I'm still missing the actual problem that will be solved ... also I'm not clear on how this hook will be invoked nor where it would reside... Dale On 5/28/15 1:56 PM, Sean P. DeNigris wrote: > Dale Henrichs-3 wrote >> Sorry for taking so long to respond ... I took time off (really off:) > NP. Glad you're back :) > > > Dale Henrichs-3 wrote >> I'm not quite sure that I understand the exact problem, so I can't tell >> what purpose a "repository moved" hook would serve. > The problem is that, when a repository is moved, there is no programmatic > way to know about it. So other configs that depend on it will keep happily > loading from the old repo. What I'm proposing is a hook e.g. > #repositoryMovedToURL so that a final config can be be committed in the old > repo with this hook, and upon being loaded will signal a resumable exception > telling that you are loading from an old repository and to where the config > has been moved. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Repository-moved-hook-tp4821832p4829176.html > Sent from the Metacello mailing list archive at Nabble.com. > -- You received this message because you are subscribed to the Google Groups "Metacello" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
Administrator
|
Sorry, yes, the language was sloppy. I meant that another repository is blessed as the canonical repository. In this case, Magritte's canonical repo used to be on Lukas' server, and then was changed to StHub. Yes, but the problem lies in configs that *depend on* the project whose canonical repo has been moved. They may never know that anything has happened and will continue to load e.g. #stable from the inactive repo, and so will not have current #stable, but a historical #stable from the point development moved. Example: I control Magritte and decide to move active development from Lukas' server to StHub. I commit a final config to Lukas' server with the hook. MagritteMagic depends on Magritte, and loads it from Lukas' server. Once I commit the config with the hook, subsequent loads of MagritteMagic generate a warning that Magritte should now be loaded from StHub/Xyz. This will give insiders who load the config the opportunity to update the MagritteMagic config with the new Magritte repo, and also will show up in CI builds and give us the same opportunity. Is that clearer?
Cheers,
Sean |
|
|
Yes that's clearer, now I am curious why you don't just publish the new
configurations in the old repository until you have updated the dependent projects to point at the new repository ... The repository hook sounds like doesn't actually fix the problem, because the poor developer is still stuck with a configuration that points to the wrong place with no real recourse but to ??? If a developer is actually happy with the older versions of everything, then the repository hook will only annoy them ... If the dependent projects are no longer maintained but still being used, then dependent projects must be moved as well and then the configs can be fixed ... Dale On 5/28/15 3:23 PM, Sean P. DeNigris wrote: > Dale Henrichs-3 wrote >> repositories aren't moved so I'm not sure what you mean ... > Sorry, yes, the language was sloppy. I meant that another repository is > blessed as the canonical repository. In this case, Magritte's canonical repo > used to be on Lukas' server, and then was changed to StHub. > > > Dale Henrichs-3 wrote >> If a new repository is being used then the configurations that are >> carried forward in the new repository should be edited to refer to the >> new repository ... > Yes, but the problem lies in configs that *depend on* the project whose > canonical repo has been moved. They may never know that anything has > happened and will continue to load e.g. #stable from the inactive repo, and > so will not have current #stable, but a historical #stable from the point > development moved. > > > Dale Henrichs-3 wrote >> I think I'm still missing the actual problem that will be solved ... >> also I'm not clear on how this hook will be invoked nor where it would >> reside... > Example: I control Magritte and decide to move active development from > Lukas' server to StHub. I commit a final config to Lukas' server with the > hook. MagritteMagic depends on Magritte, and loads it from Lukas' server. > Once I commit the config with the hook, subsequent loads of MagritteMagic > generate a warning that Magritte should now be loaded from StHub/Xyz. This > will give insiders who load the config the opportunity to update the > MagritteMagic config with the new Magritte repo, and also will show up in CI > builds and give us the same opportunity. > > Is that clearer? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Repository-moved-hook-tp4821832p4829199.html > Sent from the Metacello mailing list archive at Nabble.com. > -- You received this message because you are subscribed to the Google Groups "Metacello" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
Administrator
|
Because it's impossible to know how many dependent projects are out there. Even in this simple case, they were owned and maintained by other developers. In the simplest case of notification, the developer is now armed with the new location and can choose the most appropriate action. Of course we could provide more support built in. Good point. Maybe the warning should only get signaled if one is depending on a symbolic version, since they are moving targets, where numbered versions *should* never change...
Cheers,
Sean |
|
|
On 5/28/15 4:03 PM, Sean P. DeNigris wrote: > Dale Henrichs-3 wrote >> now I am curious why you don't just publish the new >> configurations in the old repository until you have updated the >> dependent projects to point at the new repository ... > Because it's impossible to know how many dependent projects are out there. > Even in this simple case, they were owned and maintained by other > developers. No I am talking about updating the configuration in the original repository ... in this case Lukas' repo ... if you have permissions to put in a move hook you will have permissions to slip in a proper configuration. Dale Henrichs-3 wrote >> The repository hook sounds like doesn't actually fix the problem, >> because the poor developer is still stuck with a configuration that >> points to the wrong place with no real recourse but to ??? > In the simplest case of notification, the developer is now armed with the > new location and can choose the most appropriate action. Of course we could > provide more support built in Which developer is your target audience here. The developer of MagritteMagic or the user of MagritteMagic ... the warning doesn't help the poor user of MagritteMagic and obviously the developer of MagritteMagic isn't paying attention to Magritte anymore, so what exactly do you expect this person to do with all of the information ... If you put the updated magritte configuration into the old rep and it happens to work then joy to the world the problem is fixed, if an updated configuration doesn't work then the developer IS notified that A) there is a new repo and B) a simple switch to the new repository won't fix things wither ... At this point it is time to update MagritteMagic's configuration ... which is something the user of MagritteMagic may choose to do or she may choose to ask for help ... The point is that this starts with the positive step of having a chance for "joy to the world" ... >> If a developer is actually happy with the older versions of everything, >> then the repository hook will only annoy them ... > Good point. Maybe the warning should only get signaled if one is depending > on a symbolic version, since they are moving targets, where numbered > versions *should* never change... > > And this works just fine if you publish the new config in the old repo as well (with no new features) ... in fact folks should avoid #stable symbol vesions and use numbered symbolic versions, instead and then even this warning would not be needed .... The part that I still don't get is the assumption that the new repo will magically work for an older app that was written to run against the older version in the older repo ... if someone is using an app that is dependent upon a project that has been moved, why is it important that they get pointed to the new repo in the first place considering the fact that there is no guaranteed that the old app will work with the new app ... and if there is a guarantee, because numbered symbolic versions have been used.... then a simple update of the configuration will do the trick:) At the end of the day someone has to edit a configuration to get things to work ... is that not true? Dale -- You received this message because you are subscribed to the Google Groups "Metacello" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |