4 ms·

> a copy of your code the environment does some extra epicycles to copy it outside Iceberg https://github.com/pharo-vcs/iceberg https://github.com/pharo-vcs/ic

> a copy of your code the environment does some extra epicycles to copy it outside Iceberg https://github.com/pharo-vcs/iceberg https://github.com/pharo-vcs/iceberg is the Git/etc. integration built into Pharo and works extremely well. You don't need to "file out" code if that's what you meant.

scotty79 5y ago
Do you have any examples of Pharo github repositories created with Iceberg? What do they even contain? Does Pharo even have a notion of source file?
- kencausey 5y ago
  The github link in the comment above is one such example.
  - scotty79 5y ago
    On the screens in Getting started tutorial I found this: https://github.com/pharo-spec/Spec https://github.com/pharo-spec/Spec
- igouy 5y ago
  > Does Pharo even have a notion of source file? Same as other Smalltalk implementations — VM + .image file & .sources file & .changes file. .image is a snapshot/cache .changes is recovery log text of what has been done with the .image file .sources is source code text for the .image smapshot
  - galaxyLogic 5y ago
    But, you wouldn't want to store the .sources or even .changes into git would you? The git-way is to have many small(ish) files so that you can merge them easily to another development branch. Having just 2 files in git doesn't seem to make sense. I don't know how Pharo does it but I could see that every class had its own source-file, committed to git ?
    - igouy 5y ago
      Sorry I don't have experience using Pharo with Git, so the best I can do is offer a book that Goole would have found -- https://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-ManageCode.pdf https://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-Ma...
    - 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.

scotty79 5y ago

Do you have any examples of Pharo github repositories created with Iceberg? What do they even contain? Does Pharo even have a notion of source file?

kencausey 5y ago
The github link in the comment above is one such example.
- scotty79 5y ago
  On the screens in Getting started tutorial I found this: https://github.com/pharo-spec/Spec https://github.com/pharo-spec/Spec
igouy 5y ago
> Does Pharo even have a notion of source file? Same as other Smalltalk implementations — VM + .image file & .sources file & .changes file. .image is a snapshot/cache .changes is recovery log text of what has been done with the .image file .sources is source code text for the .image smapshot
- galaxyLogic 5y ago
  But, you wouldn't want to store the .sources or even .changes into git would you? The git-way is to have many small(ish) files so that you can merge them easily to another development branch. Having just 2 files in git doesn't seem to make sense. I don't know how Pharo does it but I could see that every class had its own source-file, committed to git ?
  - igouy 5y ago
    Sorry I don't have experience using Pharo with Git, so the best I can do is offer a book that Goole would have found -- https://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-ManageCode.pdf https://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-Ma...
  - 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.