9 ms·

Kudos to them for not using the buzzword, but if you believe in the notion that 'blockchain is just a fancy buzzword that gives developers the ability to get ma

Kudos to them for not using the buzzword, but if you believe in the notion that 'blockchain is just a fancy buzzword that gives developers the ability to get managers to agree to larger budgets to clean up tech debt', this is.. blockchain programming. One problem I did find: Somewhat deeper into the tour, the tour makes the claim: > a Unison codebase can be versioned and synchronized with Git or any similar tool and will never generate a conflict in those tools. This is pratically speaking of course not true: If you have some unison codebase, whilst under the hood it's all hashes, that doesn't change the simple fact that if 2 people both check out the exact same code, and then both people make a change to how the software operates, where that change is conflicting (say, I make the green 'OK' button now red, and you make it blue), you.. have a conflict. That is a fundamental property of this interaction; no language bells and whistles can ever change this fact. So, what does happen in unison? Is it 'last committer' wins? That'd be a bit problematic. A conflict in your version control system, _IF_ it is representative of the fact that there was an actual conflict (as above with the button and the conflicting colours), is a good thing, not a bad thing.

steve_taylor 7y ago
> It is append-only: once a file in the .unison directory is created, it is never modified or deleted, and files are always named uniquely and deterministically based on their content. That's how conflicts are avoided.
- aidenn0 7y ago
  So I append X to my file and you append Y to your file, do we not have a conflict?
  - capableweb 7y ago
    Yes and no. Yes as in, if you'd like them to be merged into a new one, then you'll have to resolve a conflict. But no as in, you both appended different data, so you both have new files from the original one, as you're dealing with immutable data.
    - strbean 7y ago
      If you want to resolve merges using the workflow of git, you can generate scratch files and diff them, right?
nadam 7y ago
" I make the green 'OK' button now red, and you make it blue" I did not fully read the introduction yet, but in my mind, in a truly content-addressed system this is not a conflict: you have the hash of a main() function which ultimately makes the button red, and the other guy has a main() function that makes the button blue. No conflict in the physical sense. Yes, philosophycally there is a conflict, which is resolved by you deciding which main() function you find more useful.
- the_duke 7y ago
  Of course there are still conflicts everywhere. Developer A makes the button red, developer B changes the label from "OK" to "Accept", both inside the same function. You can't just pick one or the other, you have to combine the changes. Or two developers add two different fields to a type. Or ... Sadly the docs only have placeholders for "Concurrent work and resolving edit conflicts" and "Pull requests and collaboration". Would be very interesting to read the developers thoughts on this. The system seems to support patches, forking and merging.
  - nadam 7y ago
    Hmmm, interesting. It is getting a bit philosophical: you can view it as a conflict. But you can also view it as: hm we have these nice 2 main functions. Let's create a merged one. Kind of what was previously conflict resolution becomes part of regular programming... A slight perspective change.
    - mbrock 7y ago
      Mostly they are just not relying on Git for conflict detection and resolution, but bringing it up into the Unison system itself, in order to deal with it more gracefully and intelligently.
    - xwowsersx 7y ago
      There's nothing philosophical about it! There will exist a conflict as far as Git (or any other) version control system is concerned. That's all he saying!
Vlad_Zamfor 7y ago
Yes TFGP. This is...blockchain programming. What I find (somewhat) amusing () is that you changed your name from TTGP to TFFP. Why did she do that to you?

steve_taylor 7y ago

> It is append-only: once a file in the .unison directory is created, it is never modified or deleted, and files are always named uniquely and deterministically based on their content. That's how conflicts are avoided.

aidenn0 7y ago
So I append X to my file and you append Y to your file, do we not have a conflict?
- capableweb 7y ago
  Yes and no. Yes as in, if you'd like them to be merged into a new one, then you'll have to resolve a conflict. But no as in, you both appended different data, so you both have new files from the original one, as you're dealing with immutable data.
  - strbean 7y ago
    If you want to resolve merges using the workflow of git, you can generate scratch files and diff them, right?

nadam 7y ago

" I make the green 'OK' button now red, and you make it blue" I did not fully read the introduction yet, but in my mind, in a truly content-addressed system this is not a conflict: you have the hash of a main() function which ultimately makes the button red, and the other guy has a main() function that makes the button blue. No conflict in the physical sense. Yes, philosophycally there is a conflict, which is resolved by you deciding which main() function you find more useful.

the_duke 7y ago
Of course there are still conflicts everywhere. Developer A makes the button red, developer B changes the label from "OK" to "Accept", both inside the same function. You can't just pick one or the other, you have to combine the changes. Or two developers add two different fields to a type. Or ... Sadly the docs only have placeholders for "Concurrent work and resolving edit conflicts" and "Pull requests and collaboration". Would be very interesting to read the developers thoughts on this. The system seems to support patches, forking and merging.
- nadam 7y ago
  Hmmm, interesting. It is getting a bit philosophical: you can view it as a conflict. But you can also view it as: hm we have these nice 2 main functions. Let's create a merged one. Kind of what was previously conflict resolution becomes part of regular programming... A slight perspective change.
  - mbrock 7y ago
    Mostly they are just not relying on Git for conflict detection and resolution, but bringing it up into the Unison system itself, in order to deal with it more gracefully and intelligently.
  - xwowsersx 7y ago
    There's nothing philosophical about it! There will exist a conflict as far as Git (or any other) version control system is concerned. That's all he saying!

Vlad_Zamfor 7y ago

Yes TFGP. This is...blockchain programming. What I find (somewhat) amusing () is that you changed your name from TTGP to TFFP. Why did she do that to you?