4 ms·

Don't think of it as trading source files. Think of it as version controlling a package of class definitions. The whole idea with Smalltalk and Pharo is that

by urthor 5y ago

Don't think of it as trading source files. Think of it as version controlling a package of class definitions. The whole idea with Smalltalk and Pharo is that you don't have files. You have class definitions, and these are only version controlled in text files as a concession to the extreme populatity of GitHub. The answer is that each class definition should be seen as an atomic unit with its own version control history. Smalltalk/Pharo intrinsically doesn't focus on dealing with the Unix filesystem, because the Unix filesystem is what C deals with. And yes, the answer is Iceberg exports the package of class definitions as a text file.

imtringued 5y ago
>You have class definitions, and these are only version controlled in text files as a concession to the extreme populatity of GitHub. What prevents the pharo guys from simply providing their own merge tool and letting git call it? The only remaining issue then is showing a file system tree and diffs out of the image e.g. a simple export that doesn't necessarily even have to be importable.
- urthor 5y ago
  They did. What happened is that GitHub is titanically popular. So they went for Git integration as a compromise.
- xkriva11 5y ago
  You are missing some background. First, Pharo uses libgit2 and provides its own merging mechanism to this library. It understands the code much better than plain Git, so code merging usually has fewer conflicts. Second, for Pharo, the code (classes, methods...) are living objects. These objects are the working copy Pharo deals with. Not with the files. So it mostly works only with this object working copy + .git database. Another working copy of files (which other developers would use for editing, files outside of the .git directory) is just an additional source of problems and conflicts. Pharo has a nice Git integration, and they spent a lot of time on making it work really well. So it has functions like browsing the history of one particular method etc. You are discussing already solved problems.
  - galaxyLogic 5y ago
    > it has functions like browsing the history of one particular method etc. That is great functionality I think. Much better than basic git where changes are just changes to a set of lines. The unit of software should be classes and methods, not files. The reason git can't do this is that it is language neutral. However what I find interesting is that there is a corollary between git commits and Smalltalk snapshots. It would be great if we could "merge" Smalltalk images by checking out specific git commits and merging them together. The result would then be all the source-code in your current Smalltalk image. It is difficult if not impossible to merge two Smalltalk images. Yet it would be useful to know what are the conflicts if any between two images. Maybe Pharo already provides something in that direction?
    - igouy 5y ago
      > … if we could "merge" Smalltalk images … merge two Smalltalk images … what are the conflicts … Merge changes, not images. Even back in 1983, "Smalltalk-80: The Interactive Programming Environment" "check conflicts A prompter appears in which you type the name of a changes file. When you choose the yellow button command accept, an analysis is done of all the items in the change management browser menu to see if any of them refer to the same message selector, but specify different definitions." page 472 http://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...
galaxyLogic 5y ago
> 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.

by urthor 5y ago

imtringued 5y ago

>You have class definitions, and these are only version controlled in text files as a concession to the extreme populatity of GitHub. What prevents the pharo guys from simply providing their own merge tool and letting git call it? The only remaining issue then is showing a file system tree and diffs out of the image e.g. a simple export that doesn't necessarily even have to be importable.

urthor 5y ago
They did. What happened is that GitHub is titanically popular. So they went for Git integration as a compromise.
xkriva11 5y ago
You are missing some background. First, Pharo uses libgit2 and provides its own merging mechanism to this library. It understands the code much better than plain Git, so code merging usually has fewer conflicts. Second, for Pharo, the code (classes, methods...) are living objects. These objects are the working copy Pharo deals with. Not with the files. So it mostly works only with this object working copy + .git database. Another working copy of files (which other developers would use for editing, files outside of the .git directory) is just an additional source of problems and conflicts. Pharo has a nice Git integration, and they spent a lot of time on making it work really well. So it has functions like browsing the history of one particular method etc. You are discussing already solved problems.
- galaxyLogic 5y ago
  > it has functions like browsing the history of one particular method etc. That is great functionality I think. Much better than basic git where changes are just changes to a set of lines. The unit of software should be classes and methods, not files. The reason git can't do this is that it is language neutral. However what I find interesting is that there is a corollary between git commits and Smalltalk snapshots. It would be great if we could "merge" Smalltalk images by checking out specific git commits and merging them together. The result would then be all the source-code in your current Smalltalk image. It is difficult if not impossible to merge two Smalltalk images. Yet it would be useful to know what are the conflicts if any between two images. Maybe Pharo already provides something in that direction?
  - igouy 5y ago
    > … if we could "merge" Smalltalk images … merge two Smalltalk images … what are the conflicts … Merge changes, not images. Even back in 1983, "Smalltalk-80: The Interactive Programming Environment" "check conflicts A prompter appears in which you type the name of a changes file. When you choose the yellow button command accept, an analysis is done of all the items in the change management browser menu to see if any of them refer to the same message selector, but specify different definitions." page 472 http://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro...

galaxyLogic 5y ago

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