Smalltalk › Cincom › VisualWorks

[BUG] VW7.5 Store merge failed to mark modified package dirty

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Martin McClure

[BUG] VW7.5 Store merge failed to mark modified package dirty

I did a Store merge of a lot of packages (merged the top-level bundle).
The changes to one package consisted of only the deletion of a bunch of
shared variable definitions.

Applying the merge did delete the variables, but the package was still
marked "clean"; its version displayed as "(21,mmcclure)=". In a publish
dialog, it did not show as one of the packages to be published.

After a reconcile, it correctly showed as dirty.

This is a pretty serious problem. If I hadn't noticed, these changes
would have been lost in the merge.

I haven't tried to reproduce it under laboratory conditions. If you
cannot trivially reproduce it, let me know and I'll try to get a
reproducible case.

Regards,

-Martin

Martin McClure

Another serious problem: Re: [BUG] VW7.5 Store merge failed to mark modified package dirty

After another similar merge, I've run into another rather serious problem.

This time, the bundle version being merged into the image contained a
package into which I'd moved two methods that were previously in another
package within the bundle. The merge process does not show this as a
change. The list of "Versions being integrated:" includes the package:

GbsSingleRoundTrip(76,mmcclure)
GbsSingleRoundTrip(77,mmcclure)

But the changes do not appear in the modification list, and the methods
are not moved when modifications are applied.

I haven't yet tried this in 7.4.1, but so far I'm finding in everyday
use that the 7.5 merge is making erroneous merges far more often than
the 7.4.1 merge did.

I'm hoping we can get a patch for these problems fairly soon, as the
impact is pretty severe.

As always, if you can't readily reproduce these problems, let me know
and I'll try to help formulate a reproducible case.

Regards,

-Martin

Martin McClure wrote:

> I did a Store merge of a lot of packages (merged the top-level bundle).
> The changes to one package consisted of only the deletion of a bunch of
> shared variable definitions.
>
> Applying the merge did delete the variables, but the package was still
> marked "clean"; its version displayed as "(21,mmcclure)=". In a publish
> dialog, it did not show as one of the packages to be published.
>
> After a reconcile, it correctly showed as dirty.
>
> This is a pretty serious problem. If I hadn't noticed, these changes
> would have been lost in the merge.
>
> I haven't tried to reproduce it under laboratory conditions. If you
> cannot trivially reproduce it, let me know and I'll try to get a
> reproducible case.
>
> Regards,
>
> -Martin

Boris Popov, DeepCove Labs (SNN)

RE: Another serious problem: Re: [BUG] VW7.5 Store merge failed to mark modified package dirty

Hmm, we found that merge tool in 7.4.1 failed to even open 90% of the
time and 7.5 is actually an improvement in that regard. That's not to
say I'm against fixing issues with the new one or even improving it to
handle cases where packages are added/deleted etc.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Martin McClure [mailto:[hidden email]]
> Sent: Wednesday, May 30, 2007 2:14 PM
> To: Martin McClure
> Cc: VWNC
> Subject: Another serious problem: Re: [BUG] VW7.5 Store merge failed
to
> mark modified package dirty
>
> After another similar merge, I've run into another rather serious
problem.
>
> This time, the bundle version being merged into the image contained a
> package into which I'd moved two methods that were previously in
another
> package within the bundle. The merge process does not show this as a
> change. The list of "Versions being integrated:" includes the package:
>
> GbsSingleRoundTrip(76,mmcclure)
> GbsSingleRoundTrip(77,mmcclure)
>
> But the changes do not appear in the modification list, and the
methods

> are not moved when modifications are applied.
>
> I haven't yet tried this in 7.4.1, but so far I'm finding in everyday
> use that the 7.5 merge is making erroneous merges far more often than
> the 7.4.1 merge did.
>
> I'm hoping we can get a patch for these problems fairly soon, as the
> impact is pretty severe.
>
> As always, if you can't readily reproduce these problems, let me know
> and I'll try to help formulate a reproducible case.
>
> Regards,
>
> -Martin
>
> Martin McClure wrote:
> > I did a Store merge of a lot of packages (merged the top-level

bundle).
> > The changes to one package consisted of only the deletion of a bunch
of
> > shared variable definitions.
> >
> > Applying the merge did delete the variables, but the package was
still
> > marked "clean"; its version displayed as "(21,mmcclure)=". In a
publish

> > dialog, it did not show as one of the packages to be published.
> >
> > After a reconcile, it correctly showed as dirty.
> >
> > This is a pretty serious problem. If I hadn't noticed, these changes
> > would have been lost in the merge.
> >
> > I haven't tried to reproduce it under laboratory conditions. If you
> > cannot trivially reproduce it, let me know and I'll try to get a
> > reproducible case.
> >
> > Regards,
> >
> > -Martin

Martin McClure

Re: Another serious problem: Re: [BUG] VW7.5 Store merge failed to mark modified package dirty

Boris Popov wrote:
> Hmm, we found that merge tool in 7.4.1 failed to even open 90% of the
> time and 7.5 is actually an improvement in that regard. That's not to
> say I'm against fixing issues with the new one or even improving it to
> handle cases where packages are added/deleted etc.

I agree that the 7.5 merge tool is an improvement in many ways over its
predecessor. However, the 7.5 merge has lost changes for me twice now,
and for all its faults, I never caught the old merge tool doing that.

Regards,

-Martin

Terry Raymond

RE: Another serious problem: Re: [BUG] VW7.5 Store merge failed to mark modified package dirty

In reply to this post by Martin McClure

Martin

Do you make sure to merge only clean published packages?

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: Martin McClure [mailto:[hidden email]]
> Sent: Wednesday, May 30, 2007 5:14 PM
> To: Martin McClure
> Cc: VWNC
> Subject: Another serious problem: Re: [BUG] VW7.5 Store merge failed to
> mark modified package dirty
>
> After another similar merge, I've run into another rather serious problem.
>
> This time, the bundle version being merged into the image contained a
> package into which I'd moved two methods that were previously in another
> package within the bundle. The merge process does not show this as a
> change. The list of "Versions being integrated:" includes the package:
>
> GbsSingleRoundTrip(76,mmcclure)
> GbsSingleRoundTrip(77,mmcclure)
>
> But the changes do not appear in the modification list, and the methods
> are not moved when modifications are applied.
>
> I haven't yet tried this in 7.4.1, but so far I'm finding in everyday
> use that the 7.5 merge is making erroneous merges far more often than
> the 7.4.1 merge did.
>
> I'm hoping we can get a patch for these problems fairly soon, as the
> impact is pretty severe.
>
> As always, if you can't readily reproduce these problems, let me know
> and I'll try to help formulate a reproducible case.
>
> Regards,
>
> -Martin
>
> Martin McClure wrote:
> > I did a Store merge of a lot of packages (merged the top-level bundle).
> > The changes to one package consisted of only the deletion of a bunch of
> > shared variable definitions.
> >
> > Applying the merge did delete the variables, but the package was still
> > marked "clean"; its version displayed as "(21,mmcclure)=". In a publish
> > dialog, it did not show as one of the packages to be published.
> >
> > After a reconcile, it correctly showed as dirty.
> >
> > This is a pretty serious problem. If I hadn't noticed, these changes
> > would have been lost in the merge.
> >
> > I haven't tried to reproduce it under laboratory conditions. If you
> > cannot trivially reproduce it, let me know and I'll try to get a
> > reproducible case.
> >
> > Regards,
> >
> > -Martin

Martin McClure

Re: Another serious problem: Re: [BUG] VW7.5 Store merge failed to mark modified package dirty

Terry Raymond wrote:
> Martin
>
> Do you make sure to merge only clean published packages?

Yes, if I understand your question correctly.

Here's the process I used:

Since I started my changes to version 964 of the bundle, another team
member has published version 965, so I publish 964.1. I then load 965
into a clean image, merge 964.1 into that image, and publish 966.

Regards,

-Martin

>
>> -----Original Message-----
>> From: Martin McClure [mailto:[hidden email]]
>> Sent: Wednesday, May 30, 2007 5:14 PM
>> To: Martin McClure
>> Cc: VWNC
>> Subject: Another serious problem: Re: [BUG] VW7.5 Store merge failed to
>> mark modified package dirty
>>
>> After another similar merge, I've run into another rather serious problem.
>>
>> This time, the bundle version being merged into the image contained a
>> package into which I'd moved two methods that were previously in another
>> package within the bundle. The merge process does not show this as a
>> change. The list of "Versions being integrated:" includes the package:
>>
>> GbsSingleRoundTrip(76,mmcclure)
>> GbsSingleRoundTrip(77,mmcclure)
>>
>> But the changes do not appear in the modification list, and the methods
>> are not moved when modifications are applied.
>>
>> I haven't yet tried this in 7.4.1, but so far I'm finding in everyday
>> use that the 7.5 merge is making erroneous merges far more often than
>> the 7.4.1 merge did.
>>
>> I'm hoping we can get a patch for these problems fairly soon, as the
>> impact is pretty severe.
>>
>> As always, if you can't readily reproduce these problems, let me know
>> and I'll try to help formulate a reproducible case.
>>
>> Regards,
>>
>> -Martin
>>
>> Martin McClure wrote:
>>> I did a Store merge of a lot of packages (merged the top-level bundle).
>>> The changes to one package consisted of only the deletion of a bunch of
>>> shared variable definitions.
>>>
>>> Applying the merge did delete the variables, but the package was still
>>> marked "clean"; its version displayed as "(21,mmcclure)=". In a publish
>>> dialog, it did not show as one of the packages to be published.
>>>
>>> After a reconcile, it correctly showed as dirty.
>>>
>>> This is a pretty serious problem. If I hadn't noticed, these changes
>>> would have been lost in the merge.
>>>
>>> I haven't tried to reproduce it under laboratory conditions. If you
>>> cannot trivially reproduce it, let me know and I'll try to get a
>>> reproducible case.
>>>
>>> Regards,
>>>
>>> -Martin

Alan Knight-2

Re: Another serious problem: Re: [BUG] VW7.5 Store merge failed to mark modified package dirty

In reply to this post by Martin McClure

Trying to get a handle on this without trying all the cases. Were these extension methods before? Or afterwards? And if so, where was the class definition? And was it a system class or one of your own.

At 05:13 PM 5/30/2007, Martin McClure wrote:

After another similar merge, I've run into another rather serious problem.

This time, the bundle version being merged into the image contained a package into which I'd moved two methods that were previously in another package within the bundle. The merge process does not show this as a change. The list of "Versions being integrated:" includes the package:

GbsSingleRoundTrip(76,mmcclure)
GbsSingleRoundTrip(77,mmcclure)

But the changes do not appear in the modification list, and the methods are not moved when modifications are applied.

I haven't yet tried this in 7.4.1, but so far I'm finding in everyday use that the 7.5 merge is making erroneous merges far more often than the 7.4.1 merge did.

I'm hoping we can get a patch for these problems fairly soon, as the impact is pretty severe.

As always, if you can't readily reproduce these problems, let me know and I'll try to help formulate a reproducible case.

Regards,

-Martin

Martin McClure wrote:

I did a Store merge of a lot of packages (merged the top-level bundle).
The changes to one package consisted of only the deletion of a bunch of shared variable definitions.
Applying the merge did delete the variables, but the package was still marked "clean"; its version displayed as "(21,mmcclure)=". In a publish dialog, it did not show as one of the packages to be published.
After a reconcile, it correctly showed as dirty.
This is a pretty serious problem. If I hadn't noticed, these changes would have been lost in the merge.
I haven't tried to reproduce it under laboratory conditions. If you cannot trivially reproduce it, let me know and I'll try to get a reproducible case.
Regards,
-Martin

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Martin McClure

Re: Another serious problem: Re: [BUG] VW7.5 Store merge failed to mark modified package dirty

In reply to this post by Martin McClure

Alan Knight wrote:
> Trying to get a handle on this without trying all the cases. Were these
> extension methods before? Or afterwards? And if so, where was the class
> definition? And was it a system class or one of your own.

That would be good information to know, wouldn't it. Thanks for asking.

It's our own class. The method definitions were previously in the same
package as the class definition. The bundle being merged in moved those
methods to another package within the same bundle structure. The new
package was an immediate child of the bundle (level 1), the old package
at level 3.

Regards,

-Martin

>
> At 05:13 PM 5/30/2007, Martin McClure wrote:
>> After another similar merge, I've run into another rather serious problem.
>>
>> This time, the bundle version being merged into the image contained a
>> package into which I'd moved two methods that were previously in
>> another package within the bundle. The merge process does not show
>> this as a change. The list of "Versions being integrated:" includes
>> the package:
>>
>> GbsSingleRoundTrip(76,mmcclure)
>> GbsSingleRoundTrip(77,mmcclure)
>>
>> But the changes do not appear in the modification list, and the
>> methods are not moved when modifications are applied.
>>
>> I haven't yet tried this in 7.4.1, but so far I'm finding in everyday
>> use that the 7.5 merge is making erroneous merges far more often than
>> the 7.4.1 merge did.
>>
>> I'm hoping we can get a patch for these problems fairly soon, as the
>> impact is pretty severe.
>>
>> As always, if you can't readily reproduce these problems, let me know
>> and I'll try to help formulate a reproducible case.
>>
>> Regards,
>>
>> -Martin
>>
>> Martin McClure wrote:
>>> I did a Store merge of a lot of packages (merged the top-level bundle).
>>> The changes to one package consisted of only the deletion of a bunch
>>> of shared variable definitions.
>>> Applying the merge did delete the variables, but the package was
>>> still marked "clean"; its version displayed as "(21,mmcclure)=". In a
>>> publish dialog, it did not show as one of the packages to be published.
>>> After a reconcile, it correctly showed as dirty.
>>> This is a pretty serious problem. If I hadn't noticed, these changes
>>> would have been lost in the merge.
>>> I haven't tried to reproduce it under laboratory conditions. If you
>>> cannot trivially reproduce it, let me know and I'll try to get a
>>> reproducible case.
>>> Regards,
>>> -Martin
>
> --
> Alan Knight [|], Cincom Smalltalk Development
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>
> "The Static Typing Philosophy: Make it fast. Make it right. Make it
> run." - Niall Ross