Pijul: a distributed version control system, written in Rust (2019) • Hacker News Board

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

#81

Post by qznc » Sun, Jan 12, 2020, 8:59 AM 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?

> the role of a VCS is to CRUD changesets and branches

Then git is wrong and pijul is right for you. :)

Gits internal model is to CRUD snapshots and their relation. It would be fine if the UI would hide that but it does not. For example, gits inability to track file moves is a symptom.

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

#82

Post by pmeunier » Sun, Jan 12, 2020, 9:01 AM UTC

atq2119 wrote: post #75

aseipp wrote: post #56

Earlier quoted context omitted.

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

On cherry-pick dependencies: there is no way that any VCS can solve that problem for you, because dependencies can be (and often are, for the projects I've worked on) non-local. That is, you can have a dependency even though the changes appear to be unrelated from a textual point of view. I'm all for developing better tooling for digging into blame-history, which is more generally useful and would cover the textual d…

> but you shouldn't believe that that solves the dependency problem.

I don't think anyone believes that. The dependencies in Pijul are the minimal dependencies that make the patch application possible, they are by no means semantic (you can totally add dependencies manually, btw).

However, for the particular use case explained above (stable branches, backporting bugs), the default behaviour of Pijul already gives you something really useful.

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

#83

Post by pmeunier » Sun, Jan 12, 2020, 9:03 AM UTC

carterschonwald wrote: post #55

pmeunier wrote: post #10

Earlier quoted context omitted.

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?

The current darcs. Conflict fights are still exponential, and happen sometimes. I'm a really happy darcs user, but I was talking about complexity theory here, which considers worst cases.

For the sake of completeness, I don't know the full story for the complexity of Darcs "in most cases", but I believe it to be linear in the size of history in the normal case (as it needs to try and commute all the patches with your new patch).

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

#84

Post by pmeunier » Sun, Jan 12, 2020, 9:13 AM UTC

core-questions wrote: post #62

pmeunier wrote: post #31

Earlier quoted context omitted.

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.

Thanks, this is fascinating. I'd been hoping to move one of my teams away from Darcs to Git but they're very set in their ways; gotta assume the work to bring them to Pijul would be just as much work, but then the other teams that use Git would also need to move. Way too much CD tooling to re-implement. Would consider for a new project, somewhere else, though. I really miss my perfect understanding of SVN when I get…

> gotta assume the work to bring them to Pijul would be just as much work

Not really. If they're not heavily relying on the "darcs replace" feature, it's just the same interface. The dependencies between patches are computed differently.

Be careful though, Pijul is still 0.12, the patch format will change.

> I'd love to see this go further and have a "no conflict" merge take place

This seems possible in a future Pijul. Right now we're just starting to get text files right! Let's see in a few years.

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

#85

Post by pmeunier » Sun, Jan 12, 2020, 9:16 AM UTC

Nullabillity wrote: post #66

pmeunier wrote: post #48

Earlier quoted context omitted.

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.

Last I tried it (in November), repositories got corrupted.[0] I wish Carnix would just use Git instead, but I get why that's not happening. [0]: https://nest.pijul.com/pmeunier/carnix/discussions/39

This is a network error, not a corruption error. I agree the CLI is not yet stable.

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

#86

Post by pmeunier » Sun, Jan 12, 2020, 9:17 AM UTC

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.

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

#87

Post by pmeunier » Sun, Jan 12, 2020, 9:24 AM UTC

Nullabillity wrote: post #69

pmeunier wrote: post #51

Earlier quoted context omitted.

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

> 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. That's a reasonable reaction for someone who is very familiar with Pijul, but as a newcomer my reaction is precisely the opposite. When trying to figure out some issue I have with some software, I quickly run into two questions: 1. How did the source code look for t…

You're basically saying the Nest is still primitive. Yes it is! It's even blinking on its front page https://nest.pijul.com

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

#88

Post by [deleted] » Sun, Jan 12, 2020, 10:05 AM UTC

gcb0 wrote: post #61

pmeunier wrote: post #47

Earlier quoted context omitted.

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

> patches are associative: pulling B and C together after A does the same as pulling just C after pulling A and B that makes no sense to me. DARCS also claim this, but if you have the patches all changing the first line to a different value, obviously the last one will dictate the final value of the first line. Which is the same as git. in what world do you want to change orders of patches and not have the final stat…

[deleted]

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

#89

Post by feanaro » Sun, Jan 12, 2020, 10:05 AM UTC

dan-robertson wrote: post #71

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…

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?

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

#90

Post by _fbpt » Sun, Jan 12, 2020, 10:49 AM UTC

rumanator wrote: post #37

KirinDave wrote: post #29

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?

About half a year ago, I tried to merge two forks of a single program which had diverged by several years. I tried a Git merge, got halfway through conflict resolution, stashed my current changes and reset my repository, and could not reapply my partial resolution. (The proper approach would've been to manually run `git rerere` without arguments to save the current partial resolution, but I didn't know that).

I redid the merge in Pijul. Pijul had a bug causing it to misread the filesystem's execute bit, and no amount of `pijul reset` would fix it. Pijul's merge conflict textual syntax was baffling as well. I think it was a stack which was pushed and popped by >>> and (FamiTracker was based off the MFC GUI library. It was forked to 0CC-FamiTracker, and another fork ported it to a MFC compatibility layer with a cross-platform Qt backend. The MFC compatibility layer didn't support all the functionality used by 0CC-FamiTracker.)