On Fri, 30 Mar 2012, Edgar J. De Cleene wrote:
On 3/30/12 9:09 AM, "David T. Lewis" lewis@mail.msen.com wrote:
I have found that Bert's FixUnderscores package works well for updating the assignment characters in a package. FixUnderscores will do most of the changes, but the updates must still be checked by hand as in a case like this one.
FixUnderscores is on SqueakMap.
Dave
Very thanks, I use this next time
Also run all test before and after for sure do not break new things. My fault.
We should be able to delete wrong .mcz from trunk.
It's possible, but it's a bad idea, because it breaks the Trunk. Let me quote the rules (or guidelines) here:
"Rules of Engagement
If you have used Monticello in projects with more than two developers in the past you already know the drill. If not, here are some useful guidelines:
* Merge often. In particular when you pick up work and right before you intend to commit.
* Exercise caution. This is a running system and breaking it needlessly is generally frowned upon.
* Restrain yourself. Getting developer access doesn’t mean you are free to put in every pet extension you always wanted to have without discussion.
* If in doubt, ask. This is the corollary to the restrain yourself rule. You’re not under pressure to ship a product, so you have the time to send a note saying “hey, I’m planning to fix this old issue and it may have some side effect here or there. Anyone having a problem with that?”
I’ll add a Squeak-dev exception here: Any response from any
non-developer can be entirely ignored in this context.
* You break it, you fix it. If you change something you are generally expected to take care of the consequences, though there are some exceptions. If in doubt, ask
* Do good and talk about it. When you’re done with whatever it is you’ve been working on let people know about it. It can be as short as a note to Squeak-dev saying “hey, some of you might care that I’ve fixed the long standing bug with xyz. Update and enjoy”
* Unit Testing. Unit tests are an essential part of maintaining the reliability of our releases. New units tests are always welcome. Keep in mind that a unit test should take as little time to run as possible. Maintaining the reliability of Squeak is always easier when the tests are all green: if you break something the appearance of a new failure or error is immediately obvious and the cause is more easily found. To that end fixes for failures or errors are extremely valuable and please avoid submitting changes that cause new failures or errors."
Levente
Edgar