5 ms·

> … 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

by igouy 5y ago

> … 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/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...

smackeyacky 5y ago
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.
- igouy 5y ago
  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.)
  - smackeyacky 5y ago
    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.
    - igouy 5y ago
      > … 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?
      - smackeyacky 5y ago
        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.
        igouy 5y ago
        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.
        5y ago

by igouy 5y ago

smackeyacky 5y ago

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.

igouy 5y ago
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.)
- smackeyacky 5y ago
  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.
  - igouy 5y ago
    > … 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?
    - smackeyacky 5y ago
      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.
      - igouy 5y ago
        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.
        5y ago