pmeunier

14 ms·

91.
by pmeunier 5y ago
The linked shown above is the erroneous one, the correct one is https://pijul.org/posts/2021-02-06-rethinking-sanakirja/
92.
by pmeunier 5y ago
It is actually better documented, the design is explained in the code: https://docs.rs/sanakirja-core See for instance https://docs.rs/sanakirja-core/latest/sanakirja_core/btree/p... S
93.
by pmeunier 5y ago
Indeed. I just fixed it.
94.
by pmeunier 5y ago
One thing is somewhat subjective: liking a feature or not. However, if you're claiming to make a system including "the best" of these three tools, any reader will expect the obvious property that Jujutsu can faithfully simula
95.
by pmeunier 5y ago
Serious misunderstanding of Pijul there, Jujutsu seems more similar to Gitless. If you don't have patch commutation, or if you can't explain why your merge algorithm is more than a heuristic (in your case, both), you can't in
96.
by pmeunier 5y ago
> You didn’t mention the lack of a good theory for tree diffs/patches here. Is that because you think there is a good theory or because you think not having a theory doesn’t matter? Or just that it wasn’t worth mentioning? I'm
97.
by pmeunier 5y ago
I've thought a little bit about those when working on Pijul, there are multiple issues, mostly at the interface between the technical and the human: - There is no good diff for trees. Some formulations of the problem are NP-complete, m
98.
by pmeunier 5y ago
That could work. If your local patches are complex enough you could even rearrange them using patch commutation. At the moment, Pijul is in a state where there is just one remaining feature I want to implement before beta, with a massive ex
99.
by pmeunier 5y ago
First, you can easily import Git repos into Pijul. One issue with two-way interop is that while importing a commit into a patch is easy, doing the opposite is more complicated. Indeed, since Pijul is patch-based, there is no way to map patc
100.
by pmeunier 5y ago
First, congrats for replying to a comment asking you for concrete arguments without using any of those, nor replying directly to anything that was said. Then, I don't think you actually understand what we mean by patches: for anyone wh
101.
by pmeunier 5y ago
An easy dismissal without any solid arguments. First, saying "Darcs is slow and Pijul…" is strange, since Darcs and Pijul aim at solving the same problems. Then, Darcs has never been slow for me, I've been using it for about
102.
by pmeunier 5y ago
It is absolutely not a rewrite of Darcs, the main difference being that Darcs works with transforms only, whereas Pijul has points between the transforms, allowing it to scale to much larger repos.
103.
by pmeunier 5y ago
3-way merges suffer from two problems: - They are not "associative", as mathematicians say, which means that if a remote branch has two commits A, followed by B, merging A then B might give you a different result from merging just
104.
by pmeunier 5y ago
> (and source control systems you don't hear much about these days like darcs/pijul) A bit unfair, Darcs is indeed less fashionable nowadays because of performance issues on very large instances (which few projects actually hav
105.
by pmeunier 5y ago
> someone taking a snapshot-happy copy-on-write filesystem (btrfs, nilfs2), and putting a version control layer on top. That's actually what Pijul does under the hood, its CoW filesystem is called Sanakirja (Sanakirja is a bit more
106.
Pijul (distributed version control) getting closer to stability(pijul.org)
1 points by pmeunier 5y ago|0 comments
107.
by pmeunier 5y ago
Forgot to say: thanks! Staying on-topic in a post-mortem is hard, there are so many things involved…
108.
by pmeunier 5y ago
First, let me restate something I wrote on the post: I want my service to be free from politics, and I was ready to consider any hosting service that I could trust would allow me to do that. The word "partisan" is a bit ambiguous
109.
by pmeunier 5y ago
> I wouldn't discount your work, etcd is very stable, so it probably works very well for your use case. I had understood that, but code I don't write is code I don't have to maintain, so I'm obviously always totally o
110.
by pmeunier 5y ago
Staying at OVH, with Cloudflare in front of the servers.
111.
by pmeunier 5y ago
> do I understand that all database traffic gets routed to the leader? Do you serve read-only queries from the local replica? No, and yes. The replica have a very large ping between them, serving everything from the leader would be extre
112.
by pmeunier 5y ago
As noted on the blog post, it's also instantly mirrored to the cloud with Restic, in addition to being replicated multiple times live. The i3 notification is meant to keep a constant eye on the thing, to make sure it does happen every
113.
by pmeunier 5y ago
Thanks, that's actually why I wrote "European" rather than "in Europe", both in the blog post and in my previous comment. I'm glad to know that you agree with that distinction.
114.
by pmeunier 5y ago
OVH is the largest European cloud company. Amazon, Google and Microsoft don't count as European. As a user of both, the price different may not be 75x, but I wouldn't be surprised if it were in the 10x-20x range. The polish is als
115.
Rebuilding the infrastructure of nest.pijul.com after the OVH fire(pijul.org)
2 points by pmeunier 5y ago|0 comments
116.
by pmeunier 6y ago
> In general, the patch 'patch1 ∘ patch2' can be different from the patch 'patch2 ∘ patch1'. That isn't true. In Pijul, either patch1 explicitly depends on patch2, or patch2 explicitly depends on patch1, or else
117.
by pmeunier 6y ago
It has made huge progress lately, which was always the plan: the new data representation introduced in November 2020 made it scale to huge repositories (this was impossible before, because of disk space and speed), and then we also changed
118.
by pmeunier 6y ago
I suggest you read more about Pijul and Darcs, because you seem to be confusing Pijul patches with the output of `diff`. Patches are much easier to work with, more reliable and fully deterministic. For example, merge and rebase are the same
119.
by pmeunier 6y ago
I'm one of the authors. The concepts are different, we do have a concept called "tags" (not ready yet) which is more efficient than shallow clones, in the sense that you can make patches (commits) on top of a shallow clone wi
120.
by pmeunier 6y ago
There's zero theory on the following page: https://pijul.org/manual/why_pijul.html There are many answers: 1. Commutation makes your life easier because you can be much less careful about how you manage your branc

More ›