For git, distributed is synonymous to the replication of code and to the parallel work while offline.
What would be the equivalent of that in a live environment where some of the actors/objects/services were located somewhere else?
Consider for example mastodon, a service that has other users interacting as well? What would be the equivalent of git on that live service?
We would first need to be able to download the source code and compile it with only one button click. Still though, that wouldn’t be a live service. We would need to take the environmental closure of that service, meaning that we would have to have a default database with some values and we would need to have code that emulates other user interactions.
With a single button click, we would have replicated a live service, and we would be able to work on our code.
Not only that, with a single click, we could have made our own mastodon service.
1 Like
I see the difficulty not so much in the equivalent of Git for live systems, but in the equivalent for diff and merge.
Git is easy. It does snapshots. Ignoring efficiency for a start, download a Smalltalk image and commit it to a git repository. Let people fork it. And then have everyone commit a snapshot of the machine image once per minute. Mission accomplished.
But unless you can compute diffs between two snapshots, and apply them in a principled way to another image, the branches of snapshots are not very useful.
1 Like
I need to think about it. The problem has many different dimensions.
In the meantime, irmin is designed to be a distributed data storage with git semantics for both data and code.
https://irmin.org/
“Irmin is an OCaml library for building mergeable, branchable distributed data stores.”
If I remember correctly, you can automate conflict resolutions in irmin. Does anyone else have experience with it?
"Dynamic Behaviour
Allows users to define custom merge functions and create event-driven workflows using a notification mechanism."
Looking at just the Web page, I don’t see any claim about managing code. It’s all about data. Sure, code is data, but that’s a very superficial way of looking at code.
Also, the only reference I see to the diff/merge issue is “Allows users to define custom merge functions”. A good start, but I’d love to learn more about it. What do typical custom merge functions look like? Are there generic ones (for, say, trees)? Or are they mostly application-specific?
It seems that you define a custom type.
Code is a just text, right?
Also, it is compatible with git. So you could use the standard git program for code. And push / pull.
I only wish the type was not ocaml specific. Instead have something like wit.
1 Like
Yes, code is text, but for a library managing graph data I’d expect at least to be able to work at the AST level.
1 Like
I don’t understand. Git does not do that. The AST is specific to a language.
To put it another way, you could do it yourself. You could define the type of the AST of your preferred language and then perform version control on the AST. Of course, you would need the parser of your preferred language.
So, this is a good idea. Maybe it would be better to have both the text and the AST a la glamorous toolkit.
At least in agda, there are multiple syntax trees, but you lose information from one to the other.
This is something I am exploring as well. Different views of the code a la GT
1 Like
Sure, git does that. I don’t need a replacement for git (not for that reason at least, I’d be happy to switch for better UX). I am looking at Irmin from the point of view of “better than git”. If it handles code as well as git, then I am not interested.
I see a lot of room for improvement in handling code in version control, compared to today’s state of the art (git but also mercurial or fossil).
Different views that each have their own diff/merge - that would be interesting news!
1 Like
