There are certainly ways to fix this. So don't despair ;)
Simplest is to delete the wrong 23, 25 and 27 in the repo, and
replace it with good ones. Like, bf.23 and bf.24 from http://
source.squeakfoundation.org/inbox
Or just load bf.24 and remove the bad 23, 25, and 27 later.
I made these by first backporting edc.23 to md.22 (but removing any
trace of doing so) and saving as bf.23, and then merging edc.25
(again removing that info) before saving as bf.24. This is to get a
"clean" history for the release image, it should have worked fine
without that ancestor trickery, but the bad ancestry contained refs
to the missing versions.
I did all that in a 7105 image, the latest I found at
http://ftp.squeak.org/current_development/
Cheers,
- Bert -
On Jun 19, 2007, at 10:54 , Edgar J. De Cleene wrote:
El 6/18/07 10:26 PM, "Chris Muller" <[EMAIL PROTECTED]> escribió:
This situation was painful for me the first time it happened. The
Etoys-edc.23-with-a-different-UUID situation occurs when "edc" works
off of version 22 twice and saves two packages each with the same
name
(23).
"edc" is me , and I do the mistake, sorry
I wish Monticello would handle this better, but at least if one pays
attention, you can rename the file when you save the second "23" to
put extra characters in the filename to ensure it is unique from the
other 23. Then they can co-exist in the same repository and be
easily
merged.
But Monticello don trust names, two names with different UUID are
different
objects.
Could Monticello be tricked to think no matter the .mcz was named
(or what
UUID) to work?
Yes, was the patch sended , but people seems unconfortable with it.
This is why I try to have a new repo with right files.
Still working...
Edgar
_______________________________________________
V3dot10 mailing list
[email protected]
http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
