[squeak-dev] How to get a Trunk image

The reason why there is currently no unique update number associated with the trunk is only because nobody thus far has made a proposal as to how it should be defined. If anyone has a proposal for what to use, please make suggestions.

Colin Putney wrote:
Yes, that is equivalent to having a configuration map for every update.
Unfortunately it means that every single update consists of two package
commits; one for the contents and one for the meta package (or config map).

Cheers,
   - Andreas

On 7-Sep-09, at 11:11 PM, Andreas Raab wrote:

> Yes, that is equivalent to having a configuration map for every  
> update. Unfortunately it means that every single update consists of  
> two package commits; one for the contents and one for the meta  
> package (or config map).

Right, dependencies and configuration maps are equivalent, and so far  
we've been using config maps. An oversight on my part.

But it doesn't (necessarily) mean a commit of the config map for each  
package commit. Every time you make changes that span several packages  
(and I've seen quite a few of these in the commit messages), you can  
roll them into one config map commit. Or to reduce the overhead  
further, you could roll groups of unrelated changes into the same  
config map. What's the optimal tradeoff between overhead to create a  
new config map and the size of the delta between successive config maps?

I suppose we *already* have a unique config map number that describes  
the state of the image. Maybe we just need to increase it's resolution  
a bit? Or just start using it as is?

Colin

On 08.09.2009, at 08:51, Colin Putney wrote:


Actually, the server would know the number of all commits ever done to  
the trunk repo, simply by counting all the versions it has. That would  
be a monotonically increasing number, not quite unlike a subversion  
revision number. It may have to be a bit fancier than that to account  
for deleted versions, but not much I would guess?

warning: hand-waving and thinking aloud ahead

To make it more like a subversion revision what would be needed is  
getting back to a particular commit, that is, there would have to be a  
way to get from a revision number to the versions associated with it.  
This could be done by updating a config map whenever something is  
committed and saving it under that revision number. The config map  
would be "virtual" and simply record all the latest packages in the  
repo without respect to load order, because the server has no way of  
knowing that. This would rely on the repo usage as trunk, otherwise it  
would not be sufficient to just record the latest versions, but all  
versions would have to be associated with a revision number. Actually,  
that might be even simpler - put the revision number in the meta data  
for each submitted version. Voila. Then sorting by this number would  
give the exact sequence of trunk commits. Or ... we actually *do* have  
such an ordering already, in the upload time stamp. Wonder if it gets  
updated when moving a package between repositories ... in any case,  
old versions of the repo could simply be accessed by going to http://
s.s.o/trunk/123 which would filter out all versions after revision 123.

Or is this all silly talk? Entirely possible ;)

- Bert -

Hi!

Eliot Miranda wrote:
Just as an *obvious* note in all this: Deltas!

One of the primary goals of Deltas (the Delta part of DeltaStreams) is
to fully replace Changesets. Deltas are IMHO strictly better than
Changesets but give you the same advantages and much, much more.

Also, a Delta is an *ordered list* of changes instead of a Set which
means that a single crafted Delta can do the same as you do now with a
controlled series of Changesets. And yes, we do allow doits in Deltas,
but in a carefully *explicitly marked* way. I will post in an hour on
that sub-subject to get some feedback on the approach we are taking.

regards, Göran

Bert Freudenberg wrote:
I think that's a great idea. If there were an automatically generated
config map that gets updated on every commits in a repository it would
definitely help solve a lot of problems.

Cheers,
   - Andreas

For the records: You can now download a current trunk image at
http://ftp.squeak.org/trunk (the version is current as of today).

Cheers,
   - Andreas

Damien Cassou wrote:
> Hi,
>
> I would like to get the latest development version of Squeak (based on
> the trunk?). Where can I find an image or how can I update an old
> image?
>
> Bye
>

Hmm. When I try to load updates from this image, things go wrong. When I load updates into the image I've been working with, thing are groovy. 

Ronald Spengler wrote:
> Hmm. When I try to load updates from this image, things go wrong.

What happens?

> I've noticed that this image seems to be using the old font system.

Just in the old workspaces (I didn't actually try to make this pretty
and I don't think we have a proper ReleaseBuilder script yet for setting
things up).

> Also, when I do:
>
> TextMorph useNewEditors: true
>
> ... to enable the Cuis editors I get the unknown selector menu.

Works here.

> Is this image really up to date?

As far as I can tell, yes. I just downloaded it again and it updates
fine and everything behaves as it should.

Cheers,
   - Andreas

I was getting MNU inside Graphics-ar.63. Weirdly, I was able to consistently reproduce the issue last night, but naturally today I could not. The only thing I did differently was nuke the 'sm' and 'universetmp' directories. Do things in these get loaded automatically at startup? If so, it may have been my mistake.