5 ms·

> Don't think of it as trading source files. > Think of it as version controlling a package of class definitions. It is very useful to know whether I should lo

> Don't think of it as trading source files. > Think of it as version controlling a package of class definitions. It is very useful to know whether I should load version 1 or version 2, or 3 of a (whole) package if somebody tells me they have a new version of their great package. But main thing about git (and distributed version control) is not "trading source files". It is making changes by a distributed team to the same code-base and then being able to merge the changes made by multiple developers and having tools that help resolve conflicts between the different versions. You can and often have multiple git-repositories. So if multiple developers were working on a Smalltalk package it might make sense to create a git-repo for just that package. But if the only file is the package-file then "merging" doesn't make much sense because you can't combine files changed by one author with files changed by the other authors. So while I want to be able to 'control package versions" I also want to be able to "merge branches". And to support that it seems better to have many small files instead of a single big package file. I agree that Smalltalk should be able to do better than a typical git-application because it knows about the semantics of classes and methods. And I think Smalltalk "change-sets" are a great concept. So I'm just interested in how Pharo tries to solve the tension between big package files versus multiple developers working on small code-units at the same time.

igouy 5y ago
> And I think Smalltalk "change-sets" are a great concept. That's from way back, Smalltalk in the mid-80s. page 462, Smalltalk-80 The Interactive Programming Environment https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf Late-80s early-90s multiple developers might be using ENVY/Developer version control: https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1&dq=envy+developer&printsec=frontcover
- galaxyLogic 5y ago
  Right. But Change-sets and Change-set browser are still a great concept. I wish other programming environments would support them. You see exactly the set of changed objects you have changed or created, and can save them to a file and share that with others. One reason they work so well is that Smalltalk treats methods as objects, not just as functions defined in some file. So a change-set knows it contains specific versions of specific methods. That is not possible in a typical git-environment where the most we know about a change is that it consists of some specific lines changed in a specific file.
  - scroot 5y ago
    > One reason they work so well is that Smalltalk treats methods as objects, not just as functions defined in some file. So a change-set knows it contains specific versions of specific methods. That is not possible in a typical git-environment where the most we know about a change is that it consists of some specific lines changed in a specific file. People just coming to this might not realize that the Opensmalltalk-derived environments (Squeak, Pharo, etc) already had their own VCS system called Monticello, which worked pretty well once you understood the per-method diffs and how it was suited specifically to Smalltalk. The move to git -- Iceberg in Pharo and less so Squot for Squeak -- has left some of this behind in order to appeal to a broader base of orthodox programmers who might be otherwise scared off. It's kind of a shame.
    - urthor 5y ago
      The issue is less the version control system is my impression. The hosting infrastructure, GitHub issues and so forth, in the development community is absolutely critical these days. Social networking tools to pull a programming community together are so important. Pharo's case they've probably engineered git integration with a major goal of allowing people to contribute via GitHub issues.
  - igouy 5y ago
    Interesting perspective. Seems that I don't appreciate ChangeSet. I became accustomed to saving method changes and seeing a timestamped editions of that method; adding a version tag to what seemed like useful method editions; resolving any conflicts, then releasing a versioned method. I kind-of liked the early visibility that gave of what other people were doing.

igouy 5y ago

> And I think Smalltalk "change-sets" are a great concept. That's from way back, Smalltalk in the mid-80s. page 462, Smalltalk-80 The Interactive Programming Environment https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf Late-80s early-90s multiple developers might be using ENVY/Developer version control: https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1&dq=envy+developer&printsec=frontcover

galaxyLogic 5y ago
Right. But Change-sets and Change-set browser are still a great concept. I wish other programming environments would support them. You see exactly the set of changed objects you have changed or created, and can save them to a file and share that with others. One reason they work so well is that Smalltalk treats methods as objects, not just as functions defined in some file. So a change-set knows it contains specific versions of specific methods. That is not possible in a typical git-environment where the most we know about a change is that it consists of some specific lines changed in a specific file.
- scroot 5y ago
  > One reason they work so well is that Smalltalk treats methods as objects, not just as functions defined in some file. So a change-set knows it contains specific versions of specific methods. That is not possible in a typical git-environment where the most we know about a change is that it consists of some specific lines changed in a specific file. People just coming to this might not realize that the Opensmalltalk-derived environments (Squeak, Pharo, etc) already had their own VCS system called Monticello, which worked pretty well once you understood the per-method diffs and how it was suited specifically to Smalltalk. The move to git -- Iceberg in Pharo and less so Squot for Squeak -- has left some of this behind in order to appeal to a broader base of orthodox programmers who might be otherwise scared off. It's kind of a shame.
  - urthor 5y ago
    The issue is less the version control system is my impression. The hosting infrastructure, GitHub issues and so forth, in the development community is absolutely critical these days. Social networking tools to pull a programming community together are so important. Pharo's case they've probably engineered git integration with a major goal of allowing people to contribute via GitHub issues.
- igouy 5y ago
  Interesting perspective. Seems that I don't appreciate ChangeSet. I became accustomed to saving method changes and seeing a timestamped editions of that method; adding a version tag to what seemed like useful method editions; resolving any conflicts, then releasing a versioned method. I kind-of liked the early visibility that gave of what other people were doing.