3 ms·

Looking back now, I don’t think async software development would have worked so well without one of the older local-first software — before CDRT — git. Sure, w

by hosh 2y ago

Looking back now, I don’t think async software development would have worked so well without one of the older local-first software — before CDRT — git. Sure, we synchronize at a central point of collaboration (github and gitlab). It is having that option to do either that allows for both flexibility and reach.

marcosdumay 2y ago
It worked just fine with Subversion.
- hosh 2y ago
  I used subversion. Subversion required too much synchronization with the central server. The point is, git lets us use github, or not github. Branching is cheap, which enabled a kind of collaboration that subversion did not.
  - nradov 2y ago
    It worked just fine with Subversion. As long as the central server was fast and reliable there were no major synchronization problems. Branching was cheap, we did it every day. Git is generally better for most workflows. But let's not pretend that it was ever really necessary for remote asynchronous development work.
    - hosh 2y ago
      I was comparing git as a local first software, and earlier in the thread, comparing it to local-first food systems. One of the properties of such is resilience. Maybe there are different ideas on what local-first means. However, when that subversion server went down, that halts synchronization. If the network was not fast or reliable enough, it slows things down. Those kinds of interruptions are exactly what was called out in the article posted by the OP.
      - nradov 2y ago
        In theory, perhaps. In the real world of team software development, Subversion server reliability was way down at the bottom of our list of tooling concerns. And today most organizations drive their automated workflows from a centralized Git service. If that goes down then they can't deliver anything to customers, so they haven't really gained much resilience.
        hosh 2y ago
        Fair enough. I’ve been thinking about what a local-first software forge would look like. I have my doubts it would be commercially valuable though.

by hosh 2y ago

marcosdumay 2y ago

It worked just fine with Subversion.

hosh 2y ago
I used subversion. Subversion required too much synchronization with the central server. The point is, git lets us use github, or not github. Branching is cheap, which enabled a kind of collaboration that subversion did not.
- nradov 2y ago
  It worked just fine with Subversion. As long as the central server was fast and reliable there were no major synchronization problems. Branching was cheap, we did it every day. Git is generally better for most workflows. But let's not pretend that it was ever really necessary for remote asynchronous development work.
  - hosh 2y ago
    I was comparing git as a local first software, and earlier in the thread, comparing it to local-first food systems. One of the properties of such is resilience. Maybe there are different ideas on what local-first means. However, when that subversion server went down, that halts synchronization. If the network was not fast or reliable enough, it slows things down. Those kinds of interruptions are exactly what was called out in the article posted by the OP.
    - nradov 2y ago
      In theory, perhaps. In the real world of team software development, Subversion server reliability was way down at the bottom of our list of tooling concerns. And today most organizations drive their automated workflows from a centralized Git service. If that goes down then they can't deliver anything to customers, so they haven't really gained much resilience.
      - hosh 2y ago
        Fair enough. I’ve been thinking about what a local-first software forge would look like. I have my doubts it would be commercially valuable though.