pmeunier

28 ms·

241.
by pmeunier 7y ago
would you care to justify a little bit? The latest version is 0.x, are you talking about bugs, or something else?
242.
by pmeunier 7y ago
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,
243.
by pmeunier 7y ago
> 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 p
244.
by pmeunier 7y ago
The main point of Pijul is, you never have to think about categories when using it. It's just a sort of Git where you almost never need to branch (the equivalent of a Git branch in Pijul is just a patch), merges are always determin
245.
by pmeunier 7y ago
It's indeed not possible to make merge mistakes in Pijul, in the sense that the order between lines is always preserved: if line A comes before B in one repository, A will be before B in all repositories that have these two lines. More
246.
by pmeunier 7y ago
I'm one of the authors. Pijul is indeed heavily inspired by Darcs, but we solved that problem completely. All our algorithms are in time at most log of the size of history, which is a double-exponential improvement over Darcs' wor
247.
by pmeunier 7y ago
> The FAQ even says, “Pijul is trivial for whoever knows category theory.” Is that question really asked frequently? Words like that might convince me to never try it. ;) There have been a few blog posts after we first announced it sayin
248.
by pmeunier 7y ago
I'm one of the authors. Our goal is to make something much much easier to use than Git, and we're already succeeding in doing that. The math can be completely ignored by the user, it is just a way to guarantee that the tool will a
249.
by pmeunier 8y ago
You seem to be faster at writing than at reading, I already answered your point 1: > it becomes fairly clear if you try to cherry-pick more than twice from the same branch, and find conflicts on the way. Or when you want to "undo&qu
250.
by pmeunier 8y ago
> I would say that's less fundamental than answering "give me the exact state of the repo at time t" This is indeed a very important question when you're working alone, but the notion of "at time t" changes
251.
by pmeunier 8y ago
No, it's actually related to the ease of use and correctness. By design, Git lacks two fundamental properties that would make working with repositories much easier: 1. Git merge is not associative. This results in cases where Alice and
252.
by pmeunier 8y ago
The theory is actually quite different, even though Pijul and Darcs behave in a similar way on many examples.
253.
by pmeunier 8y ago
> the mental model will require some mental rewiring One must be pretty brave to admit that. Even though I'm a big user of Git (and a co-author of Pijul), I agree that you'll probably need to unlearn a number of things. But you
254.
by pmeunier 8y ago
One of the largest open source repositories ever: https://github.com/NixOS/nixpkgs
255.
by pmeunier 8y ago
> That commit id is a snapshot, even if it is stored as a patch. I agree with your argument, but Git does store "blobs" only (plus "trees"), and never patches. When you can ask it to show you a diff between two snapsh
256.
by pmeunier 8y ago
By the way, that guide is not from the authors of Pijul, even though as an author myself, I'm happy to see people understand it, use it and explain it. I believe a more gentle and constructive way of discussing this is by starting a di
257.
by pmeunier 8y ago
> That git works as a blob store internally (through tree objects) is, to the user, an irrelevant and hidden implementation detail. 1. Sorry, I get that you might be angry at Pijul for some reason, but this is simply not true. The lack o
258.
by pmeunier 8y ago
1. It is associative, which make it predictable, and yes, better. 2. It is commutative, which makes it non-trivial to emulate with Git, a system where nothing commutes (on purpose). Of course, you can obviously do your merges manually, reba
259.
by pmeunier 8y ago
May I suggest maybe reading the manual before writing this kind of comment? https://pijul.org/manual/why_pijul.html
260.
by pmeunier 8y ago
By having a mathematical theory of patches instead of a bunch of (user-friendly and often working) hacks. It's actually explained in the manual: https://pijul.org/manual/why_pijul.html
261.
by pmeunier 8y ago
I'm one of the authors. We are actually quite optimistic about Pijul's possibilities. In particular, there are a few niches where people either: (1) do not understand Git, can't learn it, still need a VCS. I have a few indust
262.
by pmeunier 8y ago
Sure, but if you had read the manual[1], you would have learned that this is only the associativity part, which you could indeed use to provide a better merge algorithm in a snapshot-based VCS. So: 1. You're 100% correct in saying that
263.
by pmeunier 8y ago
I'm one of the authors, and we've done a lot of bibliography before engaging in such a big project. I'll talk only about the core principles behind version control, not about how things are actually implemented, or which opti
264.
by pmeunier 8y ago
I'd say maybe check it out first, especially the parts about patch commutation and the problems with associativity in git merges and rebases.
265.
by pmeunier 9y ago
Sounds great! One thing I've always had trouble with is detecting unused dependencies. If a project grows fast, it's easy to leave some unused modules in Cargo.toml. At least, matching them with their `extern crate` counterpart he
266.
Pijul 0.4, a sound version control system written in Rust, GPL2+(pijul.org)
5 points by pmeunier 10y ago|0 comments
267.
by pmeunier 10y ago
It's that, plus a number of other things: - Rust is low-level enough to write sanakirja, which is pijul's database backend, in a clean way, without having to decode/re-encode tons of things from disk all the time. - Types! A
268.
by pmeunier 10y ago
1. Sanakirja is fully transactional. 2. Sanakirja supports fork. 3. TiKV is distributed. 4. Sanakirja was started before (the Pijul project needed something like that, and TiKV was not around).
269.
by pmeunier 10y ago
Author here! I did start Sanakirja in Finland, but I'm not a Finn, so I thought I was allowed to break that rule. Also, getting traction for Sanakirja has never really been a goal, at least not as much as getting something that we coul
270.
by pmeunier 10y ago
Fixed on nest.pijul.com/pijul_org/pijul, thanks for the report.

More ›