Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
pmeunier
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
28 ms
·
211.
▲
by
pmeunier
6y ago
Pijul is indeed vastly different and significantly more complex than WOOT, in that it handles conflicts (whereas WOOT doesn't). Conflicts are fundamental for asynchronous systems, but don't matter that much for synchronous (or alm
212.
▲
by
pmeunier
6y ago
Pijul is a CRDT. The main new idea is that it the smallest generalisation of text files that is a CRDT while keeping important properties such as the relative order of parts of the file.
213.
▲
by
pmeunier
6y ago
As one of the authors, I can tell you that Pijul development has never been as alive as today. It isn't public yet for a variety of reasons, but will be very soon.
214.
▲
by
pmeunier
6y ago
Sounds cool! What's your theory of patches? Or do you use patches only for storage (like Git in some cases)? What's the story for very large files? Also, it seems Gut hasn't had any updates for more than a year, which is even
215.
▲
by
pmeunier
6y ago
Hi! main author here. I'm about to release it, should be ready in the next few days. Most of the 6 months were spent testing and debugging it, actually.
216.
▲
by
pmeunier
6y ago
I am one of the authors of Pijul. It is indeed a semilattice, but not exactly "commutative": the only operations that commute are operations that could be done in parallel. For example, adding a file doesn't commute with edit
217.
▲
by
pmeunier
7y ago
> My question was, in that case wouldn’t Pujil need assistance too? > Your reply: “conflicts are resolved by patches” - indicates there was a conflict that needed to be resolved by a human or not? Yes, conflicts need to be resolved by
218.
▲
by
pmeunier
7y ago
> My problems only become relevant when trying to contribute to projects that already use Pijul/Nest (Carnix). Well, but then you can't blame others for using their preferred tools rather than your preferred tools. Also, Git do
219.
▲
by
pmeunier
7y ago
You don't have to use the Nest at all, Pijul can work on your own server via SSH, the protocol just runs commands through SSH.
220.
▲
by
pmeunier
7y ago
> You can build the same feature on top of pretty much any reasonable DVCS, certainly on top of git. Absolutely, the only difference is the time you'll waste managing your branches (creating, rebasing and merging them).
221.
▲
by
pmeunier
7y ago
I think you've failed to read the other answers I and others have provided. But hey, everyone should read the answers they want, if someone wants to pick only the ones that are the easiest to dismiss then have fun.
222.
▲
by
pmeunier
7y ago
> the rewrite apparently not happening in the open I'm the author of the rewrite. It will almost certainly be open source when it's done, but it is not open right now, because: - the license of the current version has not been
223.
▲
by
pmeunier
7y ago
You're basically saying the Nest is still primitive. Yes it is! It's even blinking on its front page https://nest.pijul.com
224.
▲
by
pmeunier
7y ago
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.
225.
▲
by
pmeunier
7y ago
This is a network error, not a corruption error. I agree the CLI is not yet stable.
226.
▲
by
pmeunier
7y ago
> 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 c
227.
▲
by
pmeunier
7y ago
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
228.
▲
by
pmeunier
7y ago
> 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 sema
229.
▲
by
pmeunier
7y ago
> 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
230.
▲
by
pmeunier
7y ago
Yes: these birds build their nests cooperatively .
231.
▲
by
pmeunier
7y ago
> 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.
232.
▲
by
pmeunier
7y ago
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
233.
▲
by
pmeunier
7y ago
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 mor
234.
▲
by
pmeunier
7y ago
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
235.
▲
by
pmeunier
7y ago
> 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 c
236.
▲
by
pmeunier
7y ago
In full fairness, was it Darcs version 0.x? Pijul has never made any claim to be stable yet (but we're getting there).
237.
▲
by
pmeunier
7y ago
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. L
238.
▲
by
pmeunier
7y ago
> I admit the above is a bit much for most people. True, but it's not just the UI: this also requires discipline and constant synchronisation in a team. Pijul achieves the same without much discipline.
239.
▲
by
pmeunier
7y ago
First, even though Pijul has branches, patch commutation means that most Git branches are just regular patches in Pijul. > Wouldn’t Pijul require the same too? If you're talking about my point (1) above, the answer to your question
240.
▲
by
pmeunier
7y ago
There are lots of tools out there to try and make Git simpler/more user-friendly. There's also Mercurial, which is more user-friendly while still using the same idea. Pijul is meant to model asynchronous work as just that, whereas
More ›