Comment by igouy | Hacker News Reader

Comment by igouy | Hacker News Reader

Parent Full thread

> … didn't scale to multiple users trying to share code…

Just curious, what process did you tell them to get past their "scattergun approach"?

I never looked at the 1984 "Smalltalk-80 The Interactive Programming Environment" book until about a year ago, so very much with the benefit of hindsight —

"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500)

http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...

Initially we followed that model, we would have a designated integrator that incorporated changes when you hit a milestone, and ways of filing that into other developers images as they went, but it was very error prone and a lot of regressions would pop up for the integrator as they struggled to keep up.

Envy fixed that, you could start with a fresh envy image and grab your updates. You could also isolate developers in their own branch like git and get proper warnings when you had integration issues when merging.

Basically the integration job went from full time to a couple of hours a week.

Thanks. fwiw Seems to me that what you describe is different.

> … filing that into other developers images as they went…

Seems to me that after "building a new system image" all their developers worked with that same fresh system image (built from known archived sources).

(Perhaps I'm wrong about that.)

It was a bit of a combination. We tried using pre built images but managing them got out of hand pretty quickly and there was no easy way to diff images so whoever did it had to be careful.

Then we settled on pre built images with just the across team shared code. But that got difficult too, as some teams didn't want to upgrade as quickly as others on the shared code base, so we were maintaining several versions of that.

The teams themselves had regular image consolidations saved, plus file outs and some PVCS for those, but it got increasingly harder to make a consistent merged image no matter what and devs were spinning their wheels in a kind of code merge hell at the method level that is unique to smalltalk.

Then we got envy and it fixed everything.

ParcPlace did eventually come up with a different structure for packaging and sharing code but it was too late and too simplistic to be useful.

> … code merge hell at the method level … envy and it fixed everything.

Puzzled. ENVY/Developer is still Smalltalk and code merge still method level?

Perhaps what was shared within teams and between teams changed?

Yeah, there were a lot of side channels for sharing code that made merging things more difficult than they could have been. Poor discipline when devs were in a mad rush.

Seems to me that "sharing changes amongst your team members" is much more about process than it is about tools; and the process (whatever it is) must be followed by everyone every-time.

(With the benefit of hindsight) seems to me that many teams made their mistakes with vanilla Smalltalk and avoided those same mistakes when they moved to ENVY/Developer.

Envy enforced discipline in a way, which helped a lot. Sure, the devs could have had that discipline with filed out classes but because envy made sharing code easier, they inherited that process as well.

Reply on news.ycombinator.com