broken MC versions

Hi

Due to a known, long standing bug with a trivial fix in Pharo there
are several versions in the Seaside WIP repository with the same UUID.
This obviously breaks MC. This is potentially not limited to the WIP
repository but could potentially also be the case for the main
repository. Doe anybody know a way of finding and fixing all these?

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

What versions of Pharo are affected? Is this also a problem in the
widely used Pharo 1.2.1?

What is the exact problem we get?

Finding: You could use Gofer to fetch all versions and extract the UUID.

Fixing: Not really possible, because the ancestry of all existing
verions would need to be rewritten.

Lukas

On Wednesday, 20 July 2011, Philippe Marschall
<[hidden email]> wrote:
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

To me it looks like colliding UUIDs are only a problem if different
versions with the same filename (same package, branch, version number,
initials) are committed to different repositories. I am far from any
image to verify this, but if this is the case then it is fairly easy
to avoid further problems and unlikely to have caused many problems up
to now.

Lukas

On Wednesday, 20 July 2011, Lukas Renggli <[hidden email]> wrote:
--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2011/7/20 Lukas Renggli <[hidden email]>:
> What versions of Pharo are affected? Is this also a problem in the
> widely used Pharo 1.2.1?

It looks like a VM/plugin issue, you can check whether you're affected with:

((1 to: 100) collect: [ :i |
        UUID new asString ]) asSet size


> What is the exact problem we get?

If you inspect the history of Seaside-Core-pmm.731 it gets cropped at
Seaside-Core-pmm.729 because the ancestor has the same UUID.

I don't know whether the merge code uses the same logic as the UI code.

> Finding: You could use Gofer to fetch all versions and extract the UUID.
>
> Fixing: Not really possible, because the ancestry of all existing
> verions would need to be rewritten.

Assuming only WIP versions are affected, I though more of a way to
extract and replay a change set and then commit a new version with a
different version number and UUID.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Am 20.07.2011 um 12:12 schrieb Philippe Marschall:
Can't you just merge the individual versions one after the other and save a new version?

Norbert

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2011/7/20 Norbert Hartl <[hidden email]>:
How is that supposed to help? The versions are already in the ancestry.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2011/7/20 Norbert Hartl <[hidden email]>:
Merging results in a version that has several ancestors.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2011/7/20 Philippe Marschall <[hidden email]>:
> Hi
>
> Due to a known, long standing bug with a trivial fix in Pharo there
> are several versions in the Seaside WIP repository with the same UUID.
> This obviously breaks MC. This is potentially not limited to the WIP
> repository but could potentially also be the case for the main
> repository. Doe anybody know a way of finding and fixing all these?

Attached is a csv containing all the versions with duplicate ids I
could find. The really bad cases (different versions of the _same_
package with the same UUID) are only in the WIP repository. There are
some less bad occurrences (different versions of different packages
with the same UUID) in the "trunk" 30 repository. I'll certainly have
to clean up the mess in the WIP repository (it has bad karma).

Cheers
Philippe

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2011/7/20 Lukas Renggli <[hidden email]>:
> To me it looks like colliding UUIDs are only a problem if different
> versions with the same filename (same package, branch, version number,
> initials) are committed to different repositories. I am far from any
> image to verify this, but if this is the case then it is fairly easy
> to avoid further problems and unlikely to have caused many problems up
> to now.

I'm not so sure, at least the UI breaks and MCVersionInfo >> #= only
considers the UUID.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

The duplicate UUID's are known to reek havoc with Metacello on GemStone ... Metacello fetches files into the package cache which in GemStone is a MCDictionaryRepository and #= is used for the keys ... things don't load correctly when a bunch of different packages are put into the cache with the same UUID ... I think that Esteban originally discovered the problem when he tried to load into GemStone ...

So MCDictionary repositories are definitely affected by the duplicate UUIDs

Dale

----- Original Message -----
| From: "Philippe Marschall" <[hidden email]>
| To: "Seaside - developer list" <[hidden email]>
| Sent: Wednesday, July 20, 2011 12:39:54 PM
| Subject: Re: [Seaside-dev] broken MC versions
|
| 2011/7/20 Lukas Renggli <[hidden email]>:
| > To me it looks like colliding UUIDs are only a problem if different
| > versions with the same filename (same package, branch, version
| > number,
| > initials) are committed to different repositories. I am far from
| > any
| > image to verify this, but if this is the case then it is fairly
| > easy
| > to avoid further problems and unlikely to have caused many problems
| > up
| > to now.
|
| I'm not so sure, at least the UI breaks and MCVersionInfo >> #= only
| considers the UUID.
|
| Cheers
| Philippe
| _______________________________________________
| seaside-dev mailing list
| [hidden email]
| http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
|
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2011/7/20 Dale Henrichs <[hidden email]>:
> The duplicate UUID's are known to reek havoc with Metacello on GemStone ... Metacello fetches files into the package cache which in GemStone is a MCDictionaryRepository and #= is used for the keys ... things don't load correctly when a bunch of different packages are put into the cache with the same UUID ... I think that Esteban originally discovered the problem when he tried to load into GemStone ...
>
> So MCDictionary repositories are definitely affected by the duplicate UUIDs

That's what I feared so I'll have to clean up the 30 repository as well.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

FWIW, Seside 3.0.5 has loaded cleanly into GemStone so presumably the duplicate UUIDs in the 30 repository haven't had a noticable impact on GemStone (yet)

Dale

----- Original Message -----
| From: "Philippe Marschall" <[hidden email]>
| To: "Seaside - developer list" <[hidden email]>
| Sent: Wednesday, July 20, 2011 1:35:27 PM
| Subject: Re: [Seaside-dev] broken MC versions
|
| 2011/7/20 Dale Henrichs <[hidden email]>:
| > The duplicate UUID's are known to reek havoc with Metacello on
| > GemStone ... Metacello fetches files into the package cache which
| > in GemStone is a MCDictionaryRepository and #= is used for the
| > keys ... things don't load correctly when a bunch of different
| > packages are put into the cache with the same UUID ... I think
| > that Esteban originally discovered the problem when he tried to
| > load into GemStone ...
| >
| > So MCDictionary repositories are definitely affected by the
| > duplicate UUIDs
|
| That's what I feared so I'll have to clean up the 30 repository as
| well.
|
| Cheers
| Philippe
| _______________________________________________
| seaside-dev mailing list
| [hidden email]
| http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
|
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2011/7/20 Dale Henrichs <[hidden email]>:
> FWIW, Seside 3.0.5 has loaded cleanly into GemStone so presumably the duplicate UUIDs in the 30 repository haven't had a noticable impact on GemStone (yet)

3.0.5 probably doesn't yet have them. Just don't load any of the recent code.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Ah ... that would explain it...

----- Original Message -----
| From: "Philippe Marschall" <[hidden email]>
| To: "Seaside - developer list" <[hidden email]>
| Sent: Wednesday, July 20, 2011 10:03:27 PM
| Subject: Re: [Seaside-dev] broken MC versions
|
| 2011/7/20 Dale Henrichs <[hidden email]>:
| > FWIW, Seside 3.0.5 has loaded cleanly into GemStone so presumably
| > the duplicate UUIDs in the 30 repository haven't had a noticable
| > impact on GemStone (yet)
|
| 3.0.5 probably doesn't yet have them. Just don't load any of the
| recent code.
|
| Cheers
| Philippe
| _______________________________________________
| seaside-dev mailing list
| [hidden email]
| http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
|
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2011/7/21 Dale Henrichs <[hidden email]>:
> Ah ... that would explain it...

I can confirm that 3.0.5 isn't affected. It looks like it started
right after then, you only have to pay attention to
Seaside-REST-Core-pmm.23

The following versions and everything that has them as ancestors will
have to be nuked.

Seaside-REST-Core-pmm.21
Seaside-REST-Core-DamienPollet.22
Seaside-REST-Core-pmm.23

AJP-Benchmark-pmm.5
AJP-Benchmark-pmm.4

Seaside-Benchmark-pmm.4
Seaside-Benchmark-pmm.2

Seaside-Cluster-pmm.13
Seaside-Cluster-pmm.12
Seaside-Cluster-pmm.11
Seaside-Cluster-pmm.10

Seaside-Canvas-pmm.110
Seaside-Canvas-pmm.109

Seaside-Core-pmm.729
Seaside-Core-pmm.728
Seaside-Core-pmm.727
Seaside-Core-pmm.726
Seaside-Core-pmm.725
Seaside-Core-pmm.723
Seaside-Core-pmm.722
Seaside-Core-pmm.720
Seaside-Core-pmm.716
Seaside-Core-pmm.715
Seaside-Core-pmm.713

Seaside-Development-pmm.149

Seaside-Environment-pmm.75

Seaside-Session-pmm.148
Seaside-Session-pmm.146
Seaside-Session-pmm.145
Seaside-Session-pmm.144
Seaside-Session-pmm.143
Seaside-Session-pmm.142
Seaside-Session-pmm.141

Seaside-Tests-Core-pmm.233
Seaside-Tests-Core-pmm.232
Seaside-Tests-Core-pmm.231
Seaside-Tests-Core-pmm.230
Seaside-Tests-Core-pmm.229
Seaside-Tests-Core-pmm.228
Seaside-Tests-Core-pmm.227
Seaside-Tests-Core-pmm.226
Seaside-Tests-Core-pmm.224
Seaside-Tests-Core-pmm.222
Seaside-Tests-Core-pmm.220

Seaside-Tests-HTML5-pmm.23

Seaside-Tools-OmniBrowser-pmm.22

Seaside-Tools-Web-pmm.101

Seaside-Widgets-pmm.22

Seaside-Tests-Canvas-pmm.54

Seaside-Tests-Development-pmm.40
Seaside-Tests-Development-pmm.39

Seaside-Tests-Session-pmm.53
Seaside-Tests-Session-pmm.52
Seaside-Tests-Session-pmm.51
Seaside-Tests-Session-pmm.50
Seaside-Tests-Session-pmm.49
Seaside-Tests-Session-pmm.48
Seaside-Tests-Session-pmm.47

Seaside-Tests-Flow-pmm.30

Seaside-Tests-Functional-pmm.134

Seaside-Tests-Pharo-Core-pmm.20

Seaside-Pharo-Development-pmm.51

Seaside-Pharo-Tools-Web-pmm.31

Scriptaculous-Tests-Core-pmm.60

Refactoring-Critics-pmm.10

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev