Smalltalk › Squeak › Squeak - Dev

mcd confusion

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Eliot Miranda-2

mcd confusion

Hi All,

I see through a web browser that http://source.squeak.org/trunk/Collections-ul.573.mcz exists but in an updated trunk image (Spur) with a repository browser on source.squeak.org/trunk it shows me only that Collections-ul.573(nice.572).mcd exists. What gives?

For Spur I need to patch Collections-ul.573.mcz to Collections.spur-ul.573.mcz and the automated patch code assumes it can obtain the .mcz from trunk.
--

best,

Eliot

Chris Muller-3

Re: mcd confusion

Your patch should work either way. At the level where a repository retrieves Collections-ul.573 for you, it doesn't care whether its a .mcd or .mcz; the MCVersion object you get with its embedded Snapshot to patch, will have everything as if it were loaded from a mcz..

On Wed, Jul 16, 2014 at 5:06 PM, Eliot Miranda <[hidden email]> wrote:

Hi All,

I see through a web browser that http://source.squeak.org/trunk/Collections-ul.573.mcz exists but in an updated trunk image (Spur) with a repository browser on source.squeak.org/trunk it shows me only that Collections-ul.573(nice.572).mcd exists. What gives?

For Spur I need to patch Collections-ul.573.mcz to Collections.spur-ul.573.mcz and the automated patch code assumes it can obtain the .mcz from trunk.
--
best,
Eliot

Tobias Pape

Re: mcd confusion

Hi,

On 17.07.2014, at 02:53, Chris Muller <[hidden email]> wrote:

> Your patch should work either way. At the level where a repository retrieves Collections-ul.573 for you, it doesn't care whether its a .mcd or .mcz; the MCVersion object you get with its embedded Snapshot to patch, will have everything as if it were loaded from a mcz..

Are you sure?
I do not know in depth what Eliot is patching for Spur,
but I, too, would think that a full snapshot is due here.

Eliot, does it help to flush the MC cache and scrub the package-cache?

Best
-Tobias

signature.asc (1K) Download Attachment

Eliot Miranda-2

Re: mcd confusion

Hi Tobias,

On Wed, Jul 16, 2014 at 10:56 PM, Tobias Pape <[hidden email]> wrote:

Hi,

On 17.07.2014, at 02:53, Chris Muller <[hidden email]> wrote:

> Your patch should work either way. At the level where a repository retrieves Collections-ul.573 for you, it doesn't care whether its a .mcd or .mcz; the MCVersion object you get with its embedded Snapshot to patch, will have everything as if it were loaded from a mcz..

Are you sure?]\

Chris is right. Loading the version appears to construct the full package from the patch correctly. magic ;-)

I do not know in depth what Eliot is patching for Spur,
but I, too, would think that a full snapshot is due here.

Eliot, does it help to flush the MC cache and scrub the package-cache?

Best
-Tobias

--
best,

Eliot

Bert Freudenberg

Re: mcd confusion

On 17.07.2014, at 21:47, Eliot Miranda <[hidden email]> wrote:

Hi Tobias,

On Wed, Jul 16, 2014 at 10:56 PM, Tobias Pape <[hidden email]> wrote:

Hi,

On 17.07.2014, at 02:53, Chris Muller <[hidden email]> wrote:

> Your patch should work either way. At the level where a repository retrieves Collections-ul.573 for you, it doesn't care whether its a .mcd or .mcz; the MCVersion object you get with its embedded Snapshot to patch, will have everything as if it were loaded from a mcz..

Are you sure?]\

Chris is right. Loading the version appears to construct the full package from the patch correctly. magic ;-)

Yep. MCDiffyVersions should behave exactly the same as regular MCVersions. They're just stored in multiple files, not one.

- Bert -

smime.p7s (5K) Download Attachment

Tobias Pape

Re: mcd confusion

On 18.07.2014, at 02:14, Bert Freudenberg <[hidden email]> wrote:

>
> On 17.07.2014, at 21:47, Eliot Miranda <[hidden email]> wrote:
>
>> Hi Tobias,
>>
>>
>> On Wed, Jul 16, 2014 at 10:56 PM, Tobias Pape <[hidden email]> wrote:
>> Hi,
>>
>> On 17.07.2014, at 02:53, Chris Muller <[hidden email]> wrote:
>>
>> > Your patch should work either way. At the level where a repository retrieves Collections-ul.573 for you, it doesn't care whether its a .mcd or .mcz; the MCVersion object you get with its embedded Snapshot to patch, will have everything as if it were loaded from a mcz..
>>
>> Are you sure?]\
>>
>> Chris is right. Loading the version appears to construct the full package from the patch correctly. magic ;-)
>
>
> Yep. MCDiffyVersions should behave exactly the same as regular MCVersions. They're just stored in multiple files, not one.

OK, thanks :)
I was concerned as I thought Eliot’s patching acted directly
on the snapshot.bin. Silly me.

Best
-Tobias

signature.asc (1K) Download Attachment

Eliot Miranda-2

Re: mcd confusion

On Thu, Jul 17, 2014 at 11:45 PM, Tobias Pape <[hidden email]> wrote:

On 18.07.2014, at 02:14, Bert Freudenberg <[hidden email]> wrote:

>
> On 17.07.2014, at 21:47, Eliot Miranda <[hidden email]> wrote:
>
>> Hi Tobias,
>>
>>
>> On Wed, Jul 16, 2014 at 10:56 PM, Tobias Pape <[hidden email]> wrote:
>> Hi,
>>
>> On 17.07.2014, at 02:53, Chris Muller <[hidden email]> wrote:
>>
>> > Your patch should work either way. At the level where a repository retrieves Collections-ul.573 for you, it doesn't care whether its a .mcd or .mcz; the MCVersion object you get with its embedded Snapshot to patch, will have everything as if it were loaded from a mcz..
>>
>> Are you sure?]\
>>
>> Chris is right. Loading the version appears to construct the full package from the patch correctly. magic ;-)
>
>
> Yep. MCDiffyVersions should behave exactly the same as regular MCVersions. They're just stored in multiple files, not one.

OK, thanks :)
I was concerned as I thought Eliot’s patching acted directly
on the snapshot.bin. Silly me.

That would be hairy :-). Instead it is essentially a package commit. A snapshot is created, modified and then committed. So it gets its own distinct UUID, version number and time stamp. And of course now it gets a branched package name. So these packages can safely coexist with their originals on trunk. The only bug right now is that new methods end up uncategorized and that causes a few tests to fail. Frank's CI server may encourage me to fix this soon ;-).

--
best,

Eliot