Pijul: a distributed version control system, written in Rust (2019)

Post by rumanator » Sun, Jan 12, 2020, 12:22 PM UTC

pmeunier wrote: post #52

rumanator wrote: post #40

Earlier quoted context omitted.

> but the point of Pijul is that you don't need to "do things right" to avoid the potential problems of your version control system. The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. At best, the argument made by Pijul's backers is that Pijul implements this feature differently and in a way that arguably may be creating a problem where in Git there is none.

> The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. Maybe, maybe not, but it comes with actual arguments, whereas that comment doesn't.

Post by dan-robertson » Sun, Jan 12, 2020, 12:47 PM UTC

feanaro wrote: post #89

dan-robertson wrote: post #71

Earlier quoted context omitted.

I tried to read that HOTT paper. I should preface this by saying that my homotopy type theory knowledge is basically 0 and my topology/homotopy/algebra knowledge is limited and rusty. Here are some notes I took as I read it: 1. I guess I’m starting off not understanding the relevance of this paper to distributed version control. If you have a type R for states of your repository and patches are then paths of type a =…

Regarding 2, why do you need the ability to distinguish these cases? After all, those two repositories are in the same state, which is that p is applied. The only reason you'd want to distinguish is if you want to preserve history. What about the distributed scenario makes it special?

  Alice: {p}
  Bob: {p, !p} (or do you write this as {}?)
  Charlie: {p, !p, p} = {p, !p}? So I guess this has to be {p}

  A:
  1. Alice pushes; master applies p
  2. Bob pulls, reverts p, pushes. Master reverts p
  3. Charlie pulls, reapplies, pushes. Master does ??

  B
  1. Alice pushes; master applies p
  2. Charlie pulls
  3. Bob pulls and reverts; master reverts p
  4. Charlie pushes

Post by macintux » Sun, Jan 12, 2020, 2:48 PM UTC

dan-robertson wrote: post #104

feanaro wrote: post #89

Earlier quoted context omitted.

Regarding 2, why do you need the ability to distinguish these cases? After all, those two repositories are in the same state, which is that p is applied. The only reason you'd want to distinguish is if you want to preserve history. What about the distributed scenario makes it special?

Because a DVCS has to be distributed. If Alice writes patch p, Bob reverts it, and Charlie unreverts it, you might (without contexts) have three people with different states of the repo: Alice: {p} Bob: {p, !p} (or do you write this as {}?) Charlie: {p, !p, p} = {p, !p}? So I guess this has to be {p} Suppose these people are pushing and merge if in patches to the master. Then it has no way to distinguish these scenar…

Post by vmchale » Sun, Jan 12, 2020, 5:29 PM UTC

rumanator wrote: post #44

vmchale wrote: post #42

Earlier quoted context omitted.

Compared to git, it relies on patches rather than a branch approach. I think it's more intuitive. Less opportunities to do silly things and some things that are punishing in git are not with patch-based version control.

> Compared to git, it relies on patches rather than a branch approach. Is this even relevant at all? I mean, in the user's POV the role of a VCS is to CRUD changesets and branches. As long as the user can commit their changesets and audit the DAG of past commits, who cares how the system is implemented under the hood?

Post by Eikon » Sun, Jan 12, 2020, 5:34 PM UTC

pmeunier wrote: post #86

svnpenn wrote: post #74

> This website uses cookies to ensure you get the best experience on our website. Thats the quickest way to get me to close the tab.

European laws require something like that to be said. The Nest uses cookies to authenticate you, it doesn't even give you one if you don't log in.