TextLineInterval>>#justifiedPadFor: and spurious dirty packages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

TextLineInterval>>#justifiedPadFor: and spurious dirty packages

Chris Muller-3
This method keeps appearing in my image, causing a dirty ST80 package.
 Is anyone else seeing this?  No senders, but I keep needing to revert
the package to know what I've got dirty in the image.

Also seeing some spurious class-category "changes" causing dirty
packages, even though I'm not doing any recategorizing..

Reply | Threaded
Open this post in threaded view
|

Re: TextLineInterval>>#justifiedPadFor: and spurious dirty packages

Frank Shearar-3
On 2 December 2013 20:18, Chris Muller <[hidden email]> wrote:
> This method keeps appearing in my image, causing a dirty ST80 package.
>  Is anyone else seeing this?  No senders, but I keep needing to revert
> the package to know what I've got dirty in the image.

I can't say I've seen this.

> Also seeing some spurious class-category "changes" causing dirty
> packages, even though I'm not doing any recategorizing..

I make sure nowadays that I don't issue commits with shuffled class
categories, but I certainly have done so in the past. Monticello
considers an order change in the categories to be significant, but I
vaguely remember Bert committing something to mitigate the issue.

frank

Reply | Threaded
Open this post in threaded view
|

Re: TextLineInterval>>#justifiedPadFor: and spurious dirty packages

Chris Muller-4
It appears it was due to a corrupt ancestry in 45Deprecated.  45Deprecated-fbs.3 was the version included in Squeak4.5-13352 at the FTP site, but since no future package had that version as an ancestor, everything was merged during the update, resulting in spurious dirties.

I reposted Squeak4.5-13352 with 45Deprecated-fbs.5 loaded and that seems to fix it. 


On Mon, Dec 2, 2013 at 4:04 PM, Frank Shearar <[hidden email]> wrote:
On 2 December 2013 20:18, Chris Muller <[hidden email]> wrote:
> This method keeps appearing in my image, causing a dirty ST80 package.
>  Is anyone else seeing this?  No senders, but I keep needing to revert
> the package to know what I've got dirty in the image.

I can't say I've seen this.

> Also seeing some spurious class-category "changes" causing dirty
> packages, even though I'm not doing any recategorizing..

I make sure nowadays that I don't issue commits with shuffled class
categories, but I certainly have done so in the past. Monticello
considers an order change in the categories to be significant, but I
vaguely remember Bert committing something to mitigate the issue.

frank



Reply | Threaded
Open this post in threaded view
|

Re: TextLineInterval>>#justifiedPadFor: and spurious dirty packages

Frank Shearar-3
On 02 Dec 2013, at 22:42, Chris Muller <[hidden email]> wrote:

It appears it was due to a corrupt ancestry in 45Deprecated.  45Deprecated-fbs.3 was the version included in Squeak4.5-13352 at the FTP site, but since no future package had that version as an ancestor, everything was merged during the update, resulting in spurious dirties.

I reposted Squeak4.5-13352 with 45Deprecated-fbs.5 loaded and that seems to fix it. 

Thanks for taking the time to find & fix the problem (especially since it's my fault). However, we should never replace/alter versioned artifacts. I would rather you had deleted the file and put a new file with a different name on the site. Even calling it 4.4-rc0 would work for me, but definitely not 4.5-13352.

frank

On Mon, Dec 2, 2013 at 4:04 PM, Frank Shearar <[hidden email]> wrote:
On 2 December 2013 20:18, Chris Muller <[hidden email]> wrote:
> This method keeps appearing in my image, causing a dirty ST80 package.
>  Is anyone else seeing this?  No senders, but I keep needing to revert
> the package to know what I've got dirty in the image.

I can't say I've seen this.

> Also seeing some spurious class-category "changes" causing dirty
> packages, even though I'm not doing any recategorizing..

I make sure nowadays that I don't issue commits with shuffled class
categories, but I certainly have done so in the past. Monticello
considers an order change in the categories to be significant, but I
vaguely remember Bert committing something to mitigate the issue.

frank