Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

nest.pijul.com

Post reply on HN
Print view View original

51–60 of 125 posts

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

#51

Post by pmeunier »

nemetroid wrote: post #39

The implications of Pijul are really interesting. Some of the guarantees afforded by Pijul's model are clearly superior to those afforded by Git, but I can't help but get the impression that Pijul is: 1. considerably more complex under the sheets, and 2. considerably more complex in situations you're going to have to deal with as a user . It would be nice to read an article from someone familiar with Pijul, that woul…

Hi! I'm one of the authors.

> 1. considerably more complex under the sheets, and

Yes it is, which sometimes comforts me when I think of how long it's taken to get a version that works reasonable well.

That said, it's also not the kind of complexity that goes against performance, but rather the kind that makes it hard to process Pijul repositories or patches with independent tools.

> 2. considerably more complex in situations you're going to have to deal with as a user.

I've used it quite a bit, but the biggest repository I've every interacted with is Pijul itself, which is a rather small codebase, so I don't know how the UX scales.

I find it as easy to use as Darcs, with the caveat that patches are not always as intelligible as in Darcs. That said, patches solving conflicts are weird and/or wrong in Darcs, and they are quite simple in Pijul. And I believe conflicts are the situations where you need the most simplicity and clarity.

> It would be nice to read an article from someone familiar with Pijul, [..]

That is a really nice suggestion for a blog post, it's now on my todo list. Thanks!

> For example, accurately representing repository states with files appears difficult

This is unfortunately a difficulty intrinsic to the problem. Git has the same issue, it just doesn't really show it because the conflicts that cause this are shown in a very basic way (there's only so much that diff3 can guess).

> I managed to find a few patches I couldn't understand by looking at them.

There are two issues: one is that the Nest doesn't yet have the best algorithms to render patches (but is likely to improve a lot with the new version of libpijul I'm writing), and the other one is that some patches might have been converted from a previous patch format, which makes them weird.

> I really want to like Pijul, but I'm worried that it's too powerful and requires too much from the user.

The goal is quite the opposite! For starters you can use it just like Git (with branches, and only with better merges). But then when you realise you don't need branches, everything becomes much simpler, and the tool stops getting in your way. For large Git repositories (such as NixOS/nixpkgs on GitHub), I wish it was using Pijul about 100% of the time I contribute or even use my local clone.

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

#52

Post by pmeunier »

rumanator wrote: post #40
pmeunier wrote: post #8

Earlier quoted context omitted.

> If you're doing this [..], you're doing it wrong. [..] This is not 100% true (see my answer to the second part below), 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. In the end, a version control system is just a tool, not a way of life or a work methodology. Sure, there are example projects where the Git way is the best, but they a…

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

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

#54

Post by pmeunier »

rumanator wrote: post #50
pmeunier wrote: post #46

Earlier quoted context omitted.

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

> No, the role of the file system is not to track how changesets are organiced into branches.

Oops, we just got a little bit more feature requests for a VCS than "CRUD changesets and files".

But this isn't an answer to my feature request, which was the ability to merge changes.

> Similarly, patches are only relevant as an external interface of the VCS

Why? If they're relevant as the external interface, maybe this means they model the problem better than snapshots, and should therefore be used as the implementation.

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

#55

Post by carterschonwald »

pmeunier wrote: post #10
hbbio wrote: 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.

From a complexity theory perspective, the Darcs patch application algorithm runs in time O(2^n) in the worst case, where n is the number of patches since the beginning of the repository. That exponential merge happens in practice. In Pijul, it is always O(log n + c), where c is the size of the largest conflict between the current repository and the patch you're trying to apply. So, it is a double-exponential improvem…

Are we talking about the Darcs version < 2 merge algorithm or the merge algorithm in current darcs?

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

#56

Post by aseipp »

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?

Because a thing that programmers tend to call "design" directly impacts how a user is able to interact with the tooling, obviously? Are you seriously asking "How could a thing like 'core design of the system' ever impact how someone uses it?" or are you just trolling for the sake of it?

As a real example, I used to be the maintainer of a major project that had long running stable branches. This means I needed to often cherry pick bugfixes from one place to another, but cherry picks are often difficult because they can rely on prior changes you haven't yet picked. In a system like Git, you have to cherry pick things in chronological order in order to replicate each "snapshot" of the history that the original changes came from, so the merge algorithm can figure it out. What change do you start from? Who knows! You have to find the first change that can be merged properly, or by hand, and work your way from there. You effectively have to hold the hand of the tool in cases like this.

In systems like Darcs or Pijul, that does not happen. They are always able to keep track of dependencies between patches, and so a "cherry pick" naturally implies picking change A, and all dependencies of A that are not yet available. There is no notion of having to run multiple commands or whatever; it's completely transparent. From there you can either A) accept the dependent changes or B) do surgery, for example, if you need to more carefully backport things. A) is the common case in the vast majority of uses, in my experience. Where as in Git, after a long enough time, almost any uses of 'cherry pick' will immediately fail and require you to start digging and picking out historical changes -- in Darcs, it will keep working just fine, even for dozens or a hundred dependent changes you need. The default features of the tool and their UX matter a lot, here.

If you not only can't understand how different core design choices -- like the ones in Pijul or Darcs -- can impact how a user uses a tool, but even refuse to admit that a tool could ever be used any other way: that alone is a great indictment of Git's complete and total monoculture, and precisely why these tools need to keep existing. Then again, computer programmers love having stockholm syndrome and hate reading things, so maybe it doesn't matter.

Here is a good, short video explaining the theoretical underpinning of Darcs and how they impact the user (and an old side project, "Camp", that was planned to eventually become Darcs 3). It's over a decade old and just as relevant as it ever was: https://www.youtube.com/watch?v=iOGmwA5yBn0

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

#57

Post by dan-robertson »

potiuper wrote: post #43
xoa wrote: 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…

What does HOT stand for? It’s surely not higher order types but I can’t think of anything beginning with homotopy.

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

#58

Post by the_duke »

pmeunier wrote: post #31
core-questions wrote: post #22

Earlier quoted context omitted.

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.

Well, we (the Pijul team) are trying to learn from Darcs and not disregard that aspect. Darcs maintainers have been super busy fixing the performance issues, but since Pijul doesn't have those, we can invest more time in the tooling. Look at nest.pijul.com for example, or the satellite projects such as Thrussh ( https://cargo.io/crates/thrussh ), which aim at making the UX as smooth as possible.

Correct url: https://crates.io/crates/thrussh

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

#59

Post by potiuper »

dan-robertson wrote: post #57
potiuper wrote: post #43

Earlier quoted context omitted.

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…

What does HOT stand for? It’s surely not higher order types but I can’t think of anything beginning with homotopy.

Abbreviation for Homotopy Type: https://homotopytypetheory.org/book/

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

#60

Post by the_duke »

codetrotter wrote: post #21
pmeunier wrote: post #8

Earlier quoted context omitted.

> If you're doing this [..], you're doing it wrong. [..] This is not 100% true (see my answer to the second part below), 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. In the end, a version control system is just a tool, not a way of life or a work methodology. Sure, there are example projects where the Git way is the best, but they a…

Regarding that second link about the bad merge, I think there is a deeper problem at hand. Namely that we still work with the textual representation of a program as the “source of truth”, but each time we save and commit this way, a lot of information is lost. What I would like is instead of representing source code as text to have a binary representation of the AST of the software that I am writing where, crucially,…

This seems to be exactly what the Unison language [1] tries to do.

I actually have been thinking about how the concept could be implemented for Rust.

[1] https://news.ycombinator.com/item?id=22009912

Post reply on HN