Live data from Hacker News

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

nest.pijul.com

41–50 of 125 posts

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

#41
post #3

How does it compare to Darcs? https://hackage.haskell.org/package/darcs Edit: Better link is http://darcs.net/ , darcs has been around for more than 10 years and is still actively maintained.

The problem with Darcs, which I've seen in use, is that the tooling around it is atrocious. Compared to something like Bitbucket or GHE, it's a huge pain for a bigger team, and requires a very oldschool workflow. There's a Jenkins plugin that barely works, you have to build your own new version because distro packages are old, etc. Not sure whether there's any actual advantage at all.

> the tooling around it is atrocious. Compared to something like Bitbucket

I've yet to find anything comparable for repository hosting. I use it for projects where some of github's features are frivolous, but it would be a bit goofy adopting it at a big company.

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

#42

I'm glad this made the front page. I and other of my friends have tried a few times now with varying degrees of success. For those of us pining for the days of darcs or wanting to escape the git monoculture, Pijul is really great.

What's the value proposition of Pijul? I mean, not being Git is not a good reason to convince anyone to adopt it as a VCS. A tool needs to actually be better at something and add tangible value where others may not have. What's the absolute best reason to convince anyone to adopt Pijul?

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.

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

#43
post #23

FWIW, this has gotten a certain amount of attention on HN over the years since it was begun but it's instantly noticeable that patches tailed off and stopped last June. Naturally that raises the question of "is this even still alive", and last month the starter of the project, Pierre Meunier, posted a response to a query about that indicating a major rewrite is in progress: ---- https://discourse.pijul.org/t/is-this-…

Rust or any procedural language seems not to be the most apt lang to do a first implementation / rewrite of a patch theory. Patches themselves have already been generalized to paths using HOTT ref: https://www.cs.cmu.edu/~rwh/papers/htpt/paper.pdf. The takeaway from https://arxiv.org/abs/1311.3903 is the use of commutation to allow for push out while the HOT ref discusses pseudocommutation regarding merges. See the footnote about commutation being inaccurate term regarding darts model. With the addition of ojo "ghost" deletes and pseudo edges, a formal implementation should provide a non-exponential model/algorithm amenable for optimization.

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

#44
post #42

Earlier quoted context omitted.

What's the value proposition of Pijul? I mean, not being Git is not a good reason to convince anyone to adopt it as a VCS. A tool needs to actually be better at something and add tangible value where others may not have. What's the absolute best reason to convince anyone to adopt Pijul?

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?

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

#45
post #38
post #3

How does it compare to Darcs? https://hackage.haskell.org/package/darcs Edit: Better link is http://darcs.net/ , darcs has been around for more than 10 years and is still actively maintained.

Darcs has a some pathological algorithms. IME, darcs has never lost a repo of mine and Pijul has. So I'm not clamoring to use pijul instead - I don't use darcs in a way that runs into the pathological cases anyway.

In full fairness, was it Darcs version 0.x? Pijul has never made any claim to be stable yet (but we're getting there).

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

#46
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?

> in the user's POV the role of a VCS is to CRUD changesets and branches

That would be the role of a filesystem, and Git is a perfect distributed filesystem. A VCS also allows people to merge their changes and to detect and handle conflicts gracefully.

> who cares how the system is implemented under the hood?

Pijul is not at all about the underlying implementation of commits. Patch commutation is a radically different way of thinking about cooperation, and (1) much simpler and (2) has the potential to scale to much much larger repositories.

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

#47

I'm glad this made the front page. I and other of my friends have tried a few times now with varying degrees of success. For those of us pining for the days of darcs or wanting to escape the git monoculture, Pijul is really great.

What's the value proposition of Pijul? I mean, not being Git is not a good reason to convince anyone to adopt it as a VCS. A tool needs to actually be better at something and add tangible value where others may not have. What's the absolute best reason to convince anyone to adopt Pijul?

It is not at all about not being Git. The absolute best reason is that Pijul actually has the properties that people think Git has:

- in Pijul, patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B. Git doesn't have that property: sometimes diff3 randomly (and silently) decides to shuffle lines around.

- in Pijul, patches commute. Most Git users try to simulate that by rebasing branches, but (1) that can mean a lot of extra work for no fundamental reason and (2) Git runs the same clunky merge algorithms to decide how to do it.

- Pijul knows what a conflict is, whereas Git pretends to know, but then there's "git rerere".

- in Pijul, you can clone one subdirectory of a monorepo by just pulling the patches related to that directory. Git can do partial clones as well, but only with LFS and/or submodules, which are incredibly clunky and unnatural.

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

#48
post #36

Last I tried it (a couple years ago), repositories got corrupted. I'd like something to replace darcs, but so far I haven't found it.

Well, for a project explicitly announced as experimental (there's even a blinking paragraph on nest.pijul.com), two years is quite a while.

The repository of Pijul itself got corrupted several times, but the last time was certainly more than a year ago.

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

#50

Earlier quoted context omitted.

> 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?

> in the user's POV the role of a VCS is to CRUD changesets and branches That would be the role of a filesystem, and Git is a perfect distributed filesystem. A VCS also allows people to merge their changes and to detect and handle conflicts gracefully. > who cares how the system is implemented under the hood? Pijul is not at all about the underlying implementation of commits. Patch commutation is a radically differen…

> That would be the role of a filesystem

No, the role of the file system is not to track how changesets are organiced into branches. That's the responsibility of a VCS like Git or Mercurial or Pijul. The VCS is the interface and whatever it does with the file system is an implementation detail that's abstracted away by the VCS's interface. Similarly, patches are only relevant as an external interface of the VCS, and one that users have no good reason to use.

Post reply on HN