I did a lot of work in Smalltalk earlier in my career, and it's still the best toolset I've ever used.
On one hand, yes, having the method as the unit of code is great. You just avoid all sorts of editing and versioning of non-semantic textual changes like you have in other languages. And it was really easy to look over your list of changes to see who did what when, or group them together to form larger patches.
On the other hand, collaborating with bare change sets was difficult. With no dependency tracking it was just a manually-maintained bag of class-and-method definitions. You could write those out to a file and import them into another image, but it was hard to make sure you had all the necessary bits.
This led to several Smalltalk-specific VCSs. The early ones were powerful, but basically required you to be connected to the net to do any work, because they were constantly communicating with a central server as you worked. Later ones were more snapshot based. I think Monticello was the first real distributed VCS - it preceded git by a couple of years.
What's interesting about Pijul is it gives you that "maintaining a set of patches" workflow that made early Smalltalk change management so pleasant, but also tracks dependencies between the patches so that you can easily mix and match functionality without anything getting left out.
The ultimate tool would be something that combines Pijul's theory of patches with Smalltalks semantic versioning. That would be amazing.
This is more of a cultural issue than a technical one: they want to attract mainstream programmers to their system, and the mainstream pretty much expects git compatibility.
I was the same way when I first picked up Squeak/Pharo. Only when I really went deep into it did I start to appreciate Monticello for its simplicity.
I hope that the Pharo/Squeak people keep both options around for a long time.
Git makes sense for Smalltalk in one sense: If your purpose is to create the perfect Smalltalk "image" or a set of them one after another then it makes sense that we have a single set of source and a single repository for it. This is so if you view the whole image as a single application. Like say you would view Linux as the single application whose development your VCS was created to support.
But if you view the image as a "workspace" where you are developing multiple projects and multiple components which ideally could be shared among multiple developers working on different applications, then the trad. Smalltalk change-management makes more sense. You want to track the versions of individual components/classes/modules, not just the version of the whole image. (Maybe you could call this the Cathedral vs. Bazaar?)
Saving the whole image --which Smalltalk developers do many times a day-- is similar to creating a version of your whole repository.
Individual developers do "branch" by having their own copy of the initial image. At some point they need to merge (or rather "combine" see below) some components from their images with components produced by other developers.
The difference is that in Smalltalk the merge happens by combining specific components/classes/modules, not by trying to automatically merge the whole "image".
Because of the component-based model of Smalltalk it is easy to divide the work so that each developer works just on their own classes or even on just their own methods of a class. Then "merging" is mostly a non-issue, you just combine the latest versions of different classes and methods from different developers.
Why is traditional "merging" needed in the first place? Because to accomplish something you may need to modify some existing source-file in some way. In Smalltalk instead you could subclass an existing class and make your fix there, and use the new subclass instead of modifying existing source. (Ideally).
> With no dependency tracking it was just a manually-maintained bag of class-and-method definitions
True. A simple improvement would be to make the change-list contain also the (single) previous version of every changed methods, as well as the class-definition that was in effect when the method was changed. That would not have been too much added code to carry I think.
Then maybe augment the importer so it warns if the previous versions don't match the current versions if the new versions don't match either.
In the end a tool is just a tool, to make programming easier and to find errors more easily. No tool solves all the problems. That is why I think Smalltalk was so great even if it didn't have compile-time type-checking, it was still easy and fast to spot errors in your code.
Makes sense. Coming from a Smalltalk background I had some difficulty getting used to the idea of git "commits" which are basically snapshots of the whole repository. Commit-ids are like version numbers but they apply to the whole repository, not to individual artifacts like files.
Whereas if we think in terms of patches/change-sets it is easy to think of applying a set of changes to a given artifact, and "patches" being artifacts too. Also we could have branches of patches, not just branches of the whole repository. Does Pijul work something like that, "branching patches"?
On one hand, yes, having the method as the unit of code is great. You just avoid all sorts of editing and versioning of non-semantic textual changes like you have in other languages. And it was really easy to look over your list of changes to see who did what when, or group them together to form larger patches.
On the other hand, collaborating with bare change sets was difficult. With no dependency tracking it was just a manually-maintained bag of class-and-method definitions. You could write those out to a file and import them into another image, but it was hard to make sure you had all the necessary bits.
This led to several Smalltalk-specific VCSs. The early ones were powerful, but basically required you to be connected to the net to do any work, because they were constantly communicating with a central server as you worked. Later ones were more snapshot based. I think Monticello was the first real distributed VCS - it preceded git by a couple of years.
What's interesting about Pijul is it gives you that "maintaining a set of patches" workflow that made early Smalltalk change management so pleasant, but also tracks dependencies between the patches so that you can easily mix and match functionality without anything getting left out.
The ultimate tool would be something that combines Pijul's theory of patches with Smalltalks semantic versioning. That would be amazing.