pmeunier

17 ms·

121.
by pmeunier 6y ago
To the contrary, that example actually gives a solid argument for three points where Pijul is better than Git: 1. The order between lines is preserved by Pijul. This is important: let's say Alice works at the beginning of the file (lin
122.
by pmeunier 6y ago
Pijul isn't really an "implementation" of that, for many reasons, including the fact that the paper doesn't show an algorithm to implement. However, Pijul was inspired by this, with a number of differences, including sup
123.
by pmeunier 6y ago
I'm not familiar with that thesis. Pijul uses deltas everywhere (but a special form of deltas, storing more information than the output of `diff`), plus tricks to make that fast.
124.
by pmeunier 6y ago
> It strikes me that I treat the result of git-rerere as a ridiculously weak version of this I'm the main author of Pijul, and rerere has been my main argument in every discussion about Pijul to explain how everybody is trying to
125.
by pmeunier 6y ago
I came back here to say: > I've built two commercially successful systems, This is a great achievements, congrats on that! All I was saying in my previous comment was, these very cool achievements don't prevent you from calling
126.
by pmeunier 6y ago
> The comment that RCS scales for binaries couldn't be more wrong, RCS hates binaries with a passion. That isn't what I meant, I was actually talking about Perforce. RCS doesn't even handle multiple files.
127.
by pmeunier 6y ago
(Also, our Discourse and Zulip have been pretty civil places until now, I'd like to keep it that way).
128.
by pmeunier 6y ago
Turns out I also hang out here sometimes ;-) I was about to reply point by point with arguments, but I changed my mind: I don't think I'd be interested in that conversation, the comment above is worse than a public display of a ve
129.
by pmeunier 6y ago
> Thanks to the author for an enlightening article. Thanks, I'm glad it was useful!
130.
by pmeunier 6y ago
Thanks! My understanding was that even these grammatical similarities (between Hungarian and Finnish) could be somewhat coincidental.
131.
by pmeunier 6y ago
Well, I must admit that users currently need to know a little bit about how things work in order to use it, it isn't completely foolproof. As an example, the type of channels/branches in Pijul contains things equivalent to `BTreeM
132.
by pmeunier 6y ago
The "Finno-Hugric" family is a bit controversial. That said, I speak several indo-european languages, and Farsi still sounds very exotic to me.
133.
by pmeunier 6y ago
1. Correct, my point was to emphasise that the implementation is the same. I've just updated it, thanks! 2. We often make the assumption that pages can be flushed to disk atomically, which is not very far from true on modern disks. Bec
134.
by pmeunier 6y ago
Good point. As this is a technical post following up on discussions in the Rust community (on Reddit and IRL in France), I forgot to add that word of background (I've fixed this now, thanks!).
135.
Rethinking Sanakirja, a Rust database engine with fast (zero-copy) clones(pijul.org)
8 points by pmeunier 6y ago|0 comments
136.
by pmeunier 6y ago
What we have to do in Pijul is even worse: in addition to all this, it must (1) be cross-platform and (2) avoid any user interaction, because Pijul is meant to be beginner-friendly.
137.
by pmeunier 6y ago
> Is pijul’s on-disk format stable yet? Probably. The patch format is very unlikely to change. The repository format may change a little bit still. I'd say it's probably ok to try and learn it now, but you should maybe wait for
138.
by pmeunier 6y ago
Applying a patch in Darcs usued to be in O(2^n), and now apparently O(n^2), where n is the size of history. Applying a patch in Pijul is in O(p c log n), where p is the size of the patch and c the size of the largest "deletion-insertio
139.
by pmeunier 6y ago
Well, the actual complexity of apply and unrecord is O(p c log h), where p is the size of the patch, c the size of the largest conflict in which p is involved, and h is the size of history. That makes Pijul perfectly usable, even on large r
140.
by pmeunier 6y ago
Thanks! It is a little bit challenging indeed. I've worked on worse systems before, and as always with asynchronicity, the devil is in the details, and there are more details than anyone who hasn't written it can imagine ;-) I don
141.
by pmeunier 6y ago
By the way, when I wrote "code refactoring", I didn't mean "refactor Pijul", but rather supporting the following scenario: - Alice splits a file into multiple smaller files. - In parallel, Bob changes one function.
142.
by pmeunier 6y ago
I'm the lead developer of Pijul. The theory is 99% there. Things are still moving a little bit, but it's mostly cleanup at this stage, the maths are solid. The UI is also moving, as users discover "weirdnesses" (which mo
143.
by pmeunier 6y ago
Not yet, but this is just by lack of time for implementing the diff algorithm. There's nothing hard there, but there are other priorities at the moment.
144.
by pmeunier 6y ago
On the other hand, it's still in alpha. What version did you try? Also, pijul log still depends on less, and there are some problems related to that. This is going to be fixed soon.
145.
by pmeunier 6y ago
> Is it possibly to lazy fetch the repository so you can keep H as low as possible? Like only look at H that are in conflict or something? Something like that is announced at the end of the post ;-) It will hopefully be possible within
146.
by pmeunier 6y ago
Yes it does, because Pijul has an internal model of conflicts. In particular, conflicts happen between two patches, and are solved by a patch. This means for example that when you solve a conflict on a branch, and pull from the same remote,
147.
by pmeunier 6y ago
There are global states in Pijul, using cryptographic primitives to handle the commutative nature of Pijul history. I explained it in a previous blog post: https://pijul.org/posts/2020-11-07-towards-1.0/#version-id
148.
by pmeunier 6y ago
I fixed that on the site, thanks. About recent features, I used to be very careful about using a stable Rust that was at least a few weeks old, or one generation behind. But the latest release got an unexpected number of contributors to the
149.
by pmeunier 6y ago
There are two separate things: - Git does have spurious conflicts coming back for no reason. The problem is so real that there's even a `rerere` command to take care of it. - Pijul has "minimal" conflicts, in the sense that t
150.
by pmeunier 6y ago
Did you try the following: cargo install pijul --version 1.0.0-alpha.24 Difficulties to compile have been reported on Windows, we're still trying to figure out a Windows CI pipeline.

More ›