Trunk update continuity restored
Locked
Trunk update continuity restored
 
|
Whew, I think continuous updating from 4.2 has now been fixed.
Sorry for the inconvenience and please let me know if you have any further issues. - Chris |
Re: Trunk update continuity restored
|
|
On Wed, 16 Mar 2011, Chris Muller wrote:
> Whew, I think continuous updating from 4.2 has now been fixed. > > Sorry for the inconvenience and please let me know if you have any > further issues. It's an ugly hack IMHO, but it works. I hope we won't have to use it again. But the update process is still broken. If you update your image and there's a new configuration map defined, then packages newer than those defined in the last configuration map are not loaded. You have to update your image again to make that happen. Also the mcd files don't appear in the package cache (like Tests-cmm.177(nice.155).mcd), but full mczs do, which shouldn't, like Tests-cmm.177.mcz. Levente > > - Chris > > |
Re: Trunk update continuity restored
|
|
Just as an additional note, getting the new 4.3 image that was posted, and running it using the latest Cog build results in an MNU when you try to update: MCHttpRepository >> #versionFromFileNamed: Abandoning this and trying to update again results in success. I will try to post more info when I am home and have access to my computer. Thanks, On 2011-03-16 2:25 PM, "Levente Uzonyi" <[hidden email]> wrote: |
Re: Trunk update continuity restored
|
|
In reply to this post by Levente Uzonyi-2
> But the update process is still broken. If you update your image and there's
> a new configuration map defined, then packages newer than those defined in > the last configuration map are not loaded. You have to update your image > again to make that happen. Dang it. After an entire day of working on it, I managed to get this fixed. However, there is, once again, no way out of a manual intervention. Here's what's happening: MCConfigurations package sends #versionFromFileNamed: to a MCRepository (in the Monticello package). This is a method that must eventually be removed. However, it does this *inside the loop* at the bottom of MCMcmUpdater class>>#updateFromRepositories:, so the call to that is on the stack for the entire update process. How, then, would it be possible to load a package which includes the removal of that method without disrupting the update process? I've put, like, 100 hours total into this MC upgrade, and the code is way better than it was. But because this is part of our update process itself, there is a hiccup in our update. You have to *Reject* the changes when the Merge browser is presented so that THAT update process can finish out.. After that, it's fine. This "problem" will be in "oblivion" in 6 months.. Anyone who cares enough about to see if there is a way to get around this is more than welcome. I've put as much time as I can into it. > Also the mcd files don't appear in the package cache (like > Tests-cmm.177(nice.155).mcd), but full mczs do, which shouldn't, like > Tests-cmm.177.mcz. I didn't get to this one. I'm so behind now, I'll have to look at this in a few days. mcd's are just an optimization for FileBased repositories which cannot support a fully-canonicalized model; things appear to at least be working for now. - Chris > > > Levente > >> >> - Chris >> >> > > |
Re: Trunk update continuity restored
|
|
On Wed, 16 Mar 2011, Chris Muller wrote:
>> But the update process is still broken. If you update your image and there's >> a new configuration map defined, then packages newer than those defined in >> the last configuration map are not loaded. You have to update your image >> again to make that happen. > > Dang it. After an entire day of working on it, I managed to get this fixed. > > However, there is, once again, no way out of a manual intervention. > Here's what's happening: > > MCConfigurations package sends #versionFromFileNamed: to a > MCRepository (in the Monticello package). This is a method that must > eventually be removed. > > However, it does this *inside the loop* at the bottom of MCMcmUpdater > class>>#updateFromRepositories:, so the call to that is on the stack > for the entire update process. How, then, would it be possible to > load a package which includes the removal of that method without > disrupting the update process? > > I've put, like, 100 hours total into this MC upgrade, and the code is > way better than it was. But because this is part of our update > process itself, there is a hiccup in our update. You have to *Reject* > the changes when the Merge browser is presented so that THAT update > process can finish out.. After that, it's fine. Is it possible to upload a new version that contains the merge and use that in the configuration maps? > > This "problem" will be in "oblivion" in 6 months.. Anyone who cares > enough about to see if there is a way to get around this is more than > welcome. I've put as much time as I can into it. Thanks for your time and the fixes. I know how frustrating it is when you've something that's ready, but doesn't integrate easily. > >> Also the mcd files don't appear in the package cache (like >> Tests-cmm.177(nice.155).mcd), but full mczs do, which shouldn't, like >> Tests-cmm.177.mcz. > > I didn't get to this one. I'm so behind now, I'll have to look at > this in a few days. mcd's are just an optimization for FileBased > repositories which cannot support a fully-canonicalized model; things > appear to at least be working for now. Yes, it's just and optimization which saves bandwidth and processing time on both client and server side. Levente > > - Chris > > >> >> >> Levente >> >>> >>> - Chris >>> >>> >> >> > |
Re: Trunk update continuity restored
|
|
> Is it possible to upload a new version that contains the merge and use that
> in the configuration maps? I'm not in front of it at the moment but, from my memory of late last-night: update-cmm.179 is the one that "jumps forward" the version of MC and MC-Configurations via the TrunkUpdate script. But, because the call to the old, now-deleted method is still on the execution stack, I also recompiled the method from within that same script. This, of course, leaves the Monticello package dirty and what leads to the inevitable merge-conflict once the _next_ update loads an even-newer version of Monticello. Hmm!!!! Maybe two versions both trying to delete the same method should not be regarded as a conflict! But it's too late for that now, the only tool we have to solve this problem (assuming someone cares enough to solve it, I don't) is the MCConfiguration's ability to process that TrunkScript. That's what I was doing last night, making updates to the TrunkScript preamble and changing update-cmm.179 to refer to the new version. Now, just as I'm typing here, am wondering whether the method being deleted couldn't be _moved_ to TrunkScript package (as an extension) or whether that'd result in a similar merge conflict.. Oh well.. >>> Also the mcd files don't appear in the package cache (like >>> Tests-cmm.177(nice.155).mcd), but full mczs do, which shouldn't, like >>> Tests-cmm.177.mcz. >> >> I didn't get to this one. I'm so behind now, I'll have to look at >> this in a few days. mcd's are just an optimization for FileBased >> repositories which cannot support a fully-canonicalized model; things >> appear to at least be working for now. > > Yes, it's just and optimization which saves bandwidth and processing time on > both client and server side. Sure, I totally agree. I'm just wondering whether anything I did would have any effect on this. I just tried setting the "store diffs" option on that repository (package-cache), updated from the trunk, and I had new mcd's in there and no mcz's... Or are you referring to something else? - Chris > > > Levente > >> >> - Chris >> >> >>> >>> >>> Levente >>> >>>> >>>> - Chris >>>> >>>> >>> >>> >> > > On Thu, Mar 17, 2011 at 12:49 PM, Levente Uzonyi <[hidden email]> wrote: > On Wed, 16 Mar 2011, Chris Muller wrote: > >>> But the update process is still broken. If you update your image and >>> there's >>> a new configuration map defined, then packages newer than those defined >>> in >>> the last configuration map are not loaded. You have to update your image >>> again to make that happen. >> >> Dang it. After an entire day of working on it, I managed to get this >> fixed. >> >> However, there is, once again, no way out of a manual intervention. >> Here's what's happening: >> >> MCConfigurations package sends #versionFromFileNamed: to a >> MCRepository (in the Monticello package). This is a method that must >> eventually be removed. >> >> However, it does this *inside the loop* at the bottom of MCMcmUpdater >> class>>#updateFromRepositories:, so the call to that is on the stack >> for the entire update process. How, then, would it be possible to >> load a package which includes the removal of that method without >> disrupting the update process? >> >> I've put, like, 100 hours total into this MC upgrade, and the code is >> way better than it was. But because this is part of our update >> process itself, there is a hiccup in our update. You have to *Reject* >> the changes when the Merge browser is presented so that THAT update >> process can finish out.. After that, it's fine. > > Is it possible to upload a new version that contains the merge and use that > in the configuration maps? > >> >> This "problem" will be in "oblivion" in 6 months.. Anyone who cares >> enough about to see if there is a way to get around this is more than >> welcome. I've put as much time as I can into it. > > Thanks for your time and the fixes. I know how frustrating it is when you've > something that's ready, but doesn't integrate easily. > >> >>> Also the mcd files don't appear in the package cache (like >>> Tests-cmm.177(nice.155).mcd), but full mczs do, which shouldn't, like >>> Tests-cmm.177.mcz. >> >> I didn't get to this one. I'm so behind now, I'll have to look at >> this in a few days. mcd's are just an optimization for FileBased >> repositories which cannot support a fully-canonicalized model; things >> appear to at least be working for now. > > Yes, it's just and optimization which saves bandwidth and processing time on > both client and server side. > > > Levente > >> >> - Chris >> >> >>> >>> >>> Levente >>> >>>> >>>> - Chris >>>> >>>> >>> >>> >> > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |