[squeak-dev] [Election] ...is soon upon us! Last day info
keith_hodges at yahoo.co.uk
Fri Mar 12 22:51:15 UTC 2010
> You're simply wrong on this. I, with help from others, managed to
> get the closure compiler into several dialects quite recently and I
> can assure you that changing the compiler under one's feet is
> tricky. There is nothing inherent in the trunk model that hinders
> difficult change.
When the change is finished.
You made the changes off-line using your own processes. Therefore the
development "process" is not trunk, it is whatever you used at home
because trunk wasn't appropriate for the task. Trunk is only the
publication mechanism, and I will bet the trunk process didn't help
you by making the development process easier in any way.
> A coordinated series of package updates is just as powerful as
How do you go backwards, if you are always going forwards?
> One simply has to try and try again
where? I don't have any control to un-commit stuff from trunk.
> because one will make mistakes and the system will break and one
> will be able to discover why and compensate. Don't confuse the
> medium with the message. Change sets
Are simple flexible and powerful, and file in can be implemented in
> and MC packages are
are very rigid and complex and require a specific version of MC, which
happens not to be the version I use.
> media but they can convey many messages. Eventually one gets to a
> depth at which these media fail to do the whole job (for example
> changing the object format, bytecode set etc). But Smalltalk's
> reflective nature is what makes both of these media equally powerful
> and equally unsafe. If you want to make deep changes you simply
> have to be prepared to fail, to be confused, to be persistent
Sure, you can do that in your own process at home. but you cant do it
with trunk. Being confused, and failing is my default state. So
therefore trunk is of no use to me.
More information about the Squeak-dev